DVMS Co.,Ltd

Và đây, nghĩ là làm, bên dưới sẽ là những lệnh Git thường gặp nhất, cùng tác dụng của chúng. Hy vọng các bạn sẽ được lợi từ bài viết này.

Hầu như mọi developer đều dùng Git (đại đa số là GitHub). Nhưng các lập trình viên thông thường có lẽ chỉ dùng ba lệnh sau trong… 99% trường hợp mà thôi:

Nếu bạn đang làm việc độc lập, khi hackathon, hoặc với ứng dụng “bỏ đi” thì chả sao. Nhưng khi bạn phải mở rộng và duy trì độ ổn định. Thì việc dọn dẹp commit, tuân thủ đùng chiến lược branching (phân nhánh), và viết commit message chặt chẽ trở nên rất quan trọng.

Tôi sẽ bắt đầu với một số lệnh thường thấy, để newbie cũng hiểu được Git có thể làm được gì, sau đó chuyển các các chứng năng cao cấp hơn, và cuối cùng nói đến các ví dụ điển hình nhất.

Lệnh thường dùng

Để khởi tạo Git trong một repo, bạn chỉ việc gõ dòng lệnh sau. Nếu không khởi tạo Git, bạn không thể chạy bất cứ lệnh Git nào khác trong repo đó.

git init

Nếu bạn đang sử dụng GitHub và đang push code đến một GitHub repo được lưu trữ online, thì đây chính là remote repo. Tên mặc định (còn được gọi là bí danh – alias) cho remote repo đó là origin. Nếu bạn đã sao chép một project từ GitHub, và project đã có sẵn origin rồi. Bạn có thể xem origin này bằng lệnh git remote -v (liệt kê các URL của remote repo).

Nếu bạn tự khởi tạo Git repo riêng và muốn kết hợp với một GitHub repo, bạn sẽ phải tạo Git repo trên GitHub, copy URL hiện lên, và dùng lệnh remote add origin <URL>, với URL do GitHub cung cấp thay cho “<URL>”. Từ đây, bạn có thể thêm, commit, và push đến remote repo.

Dòng lệnh cuối cùng được dùng đến khi bạn cần phải thay đổi remote repo. Giả sử bạn copy một repo từ người khác và muốn thay đổi remote repo từ của người chủ ban đầu sang tài khoản GitHub của chính mình. Hãy làm theo các bước giống như với git remote add origin, nhưng thay vào đó hãy dùng set-url để thay đổi remote repo.

Cách copy repo thông dụng nhất là dùng git clone, kèm theo URL của repo.

Nên nhớ rằng, remote repo sẽ được liên kết đến tài khoản mà bạn đã sao chép repo. Nên nếu bạn sao chép repo từ người khác, bạn sẽ không thể push sang GitHub cho đến khi thay đổi origin với các lệnh bên trên.

git clone <url>

Sớm muộn gì, bạn sẽ phải động đến branch. Và lệnh git branch sẽ liệt kê tất cả branch trên local machine. Nếu muốn tạo branch mới, bạn có thể dùng git branch <name>, với <name> là tên của branch (như “master”)

Lệnh git checkout <name> dùng để chuyển sang branch đã có. Bạn cũng có thể dùng lệnh git checkout -b <name> để tạo branch mới và chuyển qua branch đó ngay lập tức. Đa số mọi người sẽ dùng lệnh kết hợp này thay vì hai lệnh độc lập (lệnh branch và lệnh checkout).

Nếu bạn đã áp dụng một số thay đổi đến branch, giả sử gọi các thay đổi này là “develop” đi, và bạn muốn gộp (merge) branch đó vào master branch, hãy sử dụng lệnh git merge <branch>. Bạn sẽ muốn checkout master branch, sau đó chạy git merge develop để gộp develop vào master branch.

git merge <branch>

Nếu bạn đang làm việc chung với cả một team, bạn sẽ nhận thấy, khi repo được cập nhật lên GitHub, thì các thay đổi sẽ không còn local nữa. Nếu đúng như vậy, bạn có thể sử dụng git pull origin <branch> để pull các thay đổi gần nhất từ remote branch đó.

git pull origin <branch>

Lệnh cấp cao và phương pháp chuẩn

Rất nhanh, sẽ đến lúc bạn muốn commit của mình trông thật đẹp và nhất quán. Khi đó, bạn cần phải tinh chỉnh đủ thứ lên commit history để làm cho commit dễ hiểu hơn, hoặc để đảo ngược các trường hợp break change vô ý.

Lệnh git log giúp bạn xem commit history. Commit của bạn sẽ đi kèm message và một hash, (dãy số và ký tự ngẫu nhiên), ví dụ như c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Giả sử bạn push cái gì đó làm break ứng dụng. Thay vì fix cái cũ và push cái mới, bạn nên quay lại một commit và thử lần nữa.

Nếu muốn “quay về quá khứ” và checkout ứng dụng từ commit trước, bạn có thể dùng trực tiếp hash làm branch name. Như vậy, ứng dụng của bạn sẽ được tách biệt khỏi phiên bản hiện hành (vì bạn đang edit record trong history, chứ không phải phiên bản mới nhất).

git checkout c3d88eaa1aa4e4d5f

Sau đó, nếu muốn thực hiện thay đổi từ branch (trong history) đó và muốn push lần nữa, bạn phải thực hiện force push.

Chú ý: Force push rất nguy hiểm và chỉ nên thực hiện nếu thực sự cần thiết. Force push sẽ overwrite lịch sử ứng dụng và bạn sẽ mất tất cả thông tin/dữ liệu sau đó.

git push -f origin master

Đôi khi, giữ mọi thứ trong một commit duy nhất tỏ ra khá phi thực tế. Có lẽ bạn muốn lưu progress lại trước khi thử làm gì đó mới và thật… liều lĩnh, hoặc có thể bạn phạm lỗi và không muốn “vết nhơ” này xuất hiện trong version history. Vì những lý do như vậy, ta có git rebase.

Giả sử bạn có 4 commit trong local history (chưa push đến GitHub). Các commit trông rất cẩu thả và lung tung. Bạn có thể dùng rebase để kết hợp tất cả commit thành một commit ngắn gọn duy nhất.

git rebase -i HEAD~4

Lệnh trên sẽ mở editor mặc định trong máy bạn (thường là Vim), với một vài tùy chọn cho bạn thay đổi commit. Bạn sẽ thấy được đoạn code tương tự như dưới đây:

Chúng ta phải đổi từ tùy chọn “pick” sang “fixup” (như tài liệu dưới code hướng dẫn), để có thể kết hợp các commit và loại bỏ commit message. Chú ý, trong vim, bạn cần phải nhấn “a” hoặc “i” để có thể edit text; còn để save và exit, bạn phải gõ key escape kèm tổ hợp phím “shift + z + z”.

Đoạn lệnh này sẽ merge toàn bộ commit thành một commit duy nhất với message “oldest commit message”.

Bước tiếp theo, bạn sẽ phải rename commit message. Cách rename cũng không có quy củ chuẩn mực cụ thể, muốn đặt sao thì đặt, miễn là bạn đi theo một hình mẫu. Commit guidelines put out by Google for Angular.js là một hướng dẫn khá hay cho các bạn.

Để thay đổi commit message, hãy dùng flag amend.

git commit --amend

Lệnh này cũng sẽ mở vim, và quy luật edit text và save cũng giống y như trên. Sau đây là một commit message chuẩn dựa theo một trong các quy luật của guideline:

Khi đi theo các types (kiểu) được nhắc đến trong guideline, ta có thể viết change log dễ dàng hơn. Bạn cũng có thể thêm thông tin vào footer (một lần nữa, được xác định rõ trong guideline) có nhắc đến vấn đề.

Lưu ý: Nên tránh rebase và squash commit nếu bạn đang làm project nhóm, và có code được push lên GitHub. Nếu bạn “tự nhiên” thay đổi version history mà không thông báo, rất nhiều thành viên khác sẽ gặp khó khăn với bug.

Với Git, bạn có thể kết hợp và sử dụng hằng hà vô số kiểu lệnh cho nhiều mục đích khác nhau. Nhưng nếu bạn mới đến với Git, những dòng lệnh trên cũng quá đủ cho bạn dùng vài năm rồi.

freecodecamp

DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...

Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…

Quý khách xem Hồ sơ năng lực của DVMS tại đây >>

Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>