6 lệnh Git cơ bản và quy trình sử dụng Git trong làm việc nhóm

Vì sao nhóm nào cũng "dính" lỗi Git ít nhất một lần?

Không phải vì Git khó. Vấn đề thường nằm ở chỗ cả nhóm bắt đầu code trước khi thống nhất cách làm việc chung. Kết quả quen thuộc: một bạn push thẳng lên main, một bạn khác git pull thì báo conflict đỏ lòm, và không ai dám merge vì sợ hỏng code của người khác.

Tin tốt là chỉ cần thống nhất ba điều sau trước buổi code đầu tiên, nhóm đã tránh được phần lớn rắc rối:

Phần còn lại của bài này không chỉ liệt kê lệnh, mà đi qua cả quy trình thực tế và những tình huống hay khiến sinh viên bối rối nhất.

6 lệnh Git đủ dùng để bắt đầu

Không cần học thuộc cả bảng lệnh Git ngay từ đầu. Sáu lệnh dưới đây là những gì bạn sẽ gõ nhiều nhất trong một đồ án nhóm.

1. git clone — tải project về máy

Dùng khi bạn mới tham gia và repository đã tồn tại trên GitHub.

git clone <repository-url>

Mẹo nhỏ: sau khi clone, hãy mở file README.md (nếu có) trước khi code dòng nào — thường nó ghi cách chạy project, biến môi trường cần thiết, hoặc lệnh cài đặt thư viện.

2. git status — biết mình đang đứng ở đâu

Lệnh này nên gõ trước mọi hành động khác. Nó cho biết bạn đang ở nhánh nào, file nào đã sửa, file nào đã stage.

git status

Thói quen tốt: gõ git status trước khi git add, và gõ lại lần nữa sau khi git add để chắc chắn bạn không quên hoặc thêm nhầm file.

3. git switch -c — tạo nhánh riêng cho từng việc

git switch -c feature/ten-chuc-nang

Đặt tên nhánh theo việc đang làm, không đặt tên theo tên người. feature/login-form dễ hiểu hơn nhiều so với nhanh-cua-minh khi cả nhóm nhìn vào danh sách nhánh trên GitHub.

4. git add — chọn thay đổi sẽ được lưu

git add .

Với dự án thật, tránh thói quen git add . một cách vô thức. Hãy chạy git status trước để chắc bạn không vô tình add file .env, file node_modules, hay file cấu hình IDE của riêng mình. Cách an toàn hơn là tạo file .gitignore ngay từ commit đầu tiên, liệt kê những thứ không nên lên GitHub:

node_modules/
.env
.DS_Store
dist/

5. git commit — lưu một mốc thay đổi có ý nghĩa

git commit -m "feat: them trang dang nhap"

Commit nhỏ và rõ mục đích sẽ giúp cả nhóm dễ dò lại lịch sử khi có bug. Nếu muốn commit message chuyên nghiệp hơn, có thể theo mẫu:

• feat: — thêm chức năng mới
• fix: — sửa lỗi
• refactor: — sửa cấu trúc code, không đổi hành vi
• docs: — chỉnh sửa tài liệu

Một commit gộp 15 file thay đổi không liên quan gì đến nhau sẽ rất khó review và gần như không thể revert an toàn nếu sau này phát hiện lỗi.

6. git pull — cập nhật code mới nhất trước khi làm tiếp

git pull origin main

Quy tắc nhỏ nhưng cứu được rất nhiều lần conflict: luôn git pull origin main trước khi tạo nhánh mới, không phải sau khi đã code xong.

Quy trình làm việc nhóm nên áp dụng

Đây là quy trình gọn, phù hợp với đồ án môn học hoặc dự án nhỏ 2–5 người. Mỗi thành viên lặp lại các bước này cho mỗi đầu việc được giao.

1. Nhận việc rõ ràng. "Tạo form đăng nhập" là một đầu việc cụ thể. "Làm phần auth" thì không — nó dễ chồng lấn với việc của người khác.
2. Cập nhật main trước khi bắt đầu. Luôn xuất phát từ phiên bản mới nhất, tránh code trên nền code cũ rồi conflict sau này.
3. Tạo nhánh theo đầu việc. Ví dụ feature/login-form hoặc fix/header-mobile.
4. Code và commit từng phần nhỏ. Mỗi khi một phần chạy được, git status → git add → git commit. Đừng để đến cuối ngày mới commit một lần duy nhất.
5. Đẩy nhánh và mở Pull Request. Viết mô tả ngắn: làm gì, test bằng cách nào, cần ai review phần nào.
6. Xóa nhánh sau khi merge. Nhánh đã merge xong nên xóa (trên GitHub có nút "Delete branch" ngay sau khi merge) để danh sách nhánh không rối theo thời gian.

git switch main
git pull origin main
git switch -c feature/login-form
# code, kiem tra va commit
git push -u origin feature/login-form

Những tình huống hay khiến sinh viên bối rối

Conflict khi git pull

Conflict không có nghĩa là bạn làm sai — nó chỉ báo hai người đã sửa cùng một vùng code. Khi Git dừng lại và hiện các ký hiệu <<<<<<<, =======, >>>>>>> trong file, hãy:

1. Đọc cả hai phiên bản để hiểu mỗi bên đang làm gì.
2. Giữ lại phần đúng (có thể là kết hợp cả hai), xóa hết các ký hiệu đánh dấu.
3. Chạy lại ứng dụng để chắc code không bị gãy.
4. git add file đã sửa rồi git commit để hoàn tất việc merge.

Nếu không chắc đoạn code bị conflict dùng để làm gì, đừng đoán rồi tự sửa. Hỏi người đã viết đoạn đó, hoặc gọi nhanh 5 phút để cùng quyết định — nhanh hơn nhiều so với việc tự sửa sai rồi tạo thêm bug mới đè lên bug cũ.

Commit nhầm lên main

Nếu lỡ commit trực tiếp lên main mà chưa push, có thể chuyển commit đó sang nhánh mới mà không mất code:

git switch -c feature/sua-nham
git switch main
git reset --hard origin/main

Lệnh git reset --hard sẽ xóa thay đổi trên nhánh hiện tại, nên chỉ dùng khi chắc chắn code đã được chuyển an toàn sang nhánh mới ở bước trên.

Muốn lưu tạm code dở dang để chuyển việc khác

Khi đang code dở mà cần chuyển sang nhánh khác gấp (ví dụ fix bug khẩn), đừng commit code dở dang chỉ để "lưu tạm". Dùng git stash để cất thay đổi sang một chỗ riêng:

git stash
git switch fix/bug-khan
# xu ly xong, quay lai
git switch feature/dang-lam
git stash pop

Push bị từ chối vì nhánh remote đã có thay đổi mới

Thường xảy ra khi hai người cùng làm chung một nhánh. Trước khi push, kéo thay đổi mới nhất về:

git pull origin ten-nhanh

Xử lý conflict nếu có, rồi push lại. Tránh dùng git push --force trừ khi thật sự hiểu hậu quả — lệnh này có thể ghi đè và xóa mất commit của người khác trên nhánh chung.

Checklist trước khi mở Pull Request

Tóm lại

Git sẽ bớt đáng sợ khi bạn dùng nó thường xuyên với một quy trình đơn giản, thống nhất từ đầu trong cả nhóm. Bắt đầu với clone, status, switch, add, commit, pull — nắm chắc sáu lệnh này là đủ để làm việc an toàn. Phần quan trọng hơn cả lệnh là thói quen: pull trước khi code, commit nhỏ và rõ ràng, và biến Pull Request thành điểm hẹn để cả nhóm cùng kiểm tra code trước khi đưa vào main.