Với team nhỏ, Git thường bắt đầu rất tự nhiên: mọi người cùng đẩy code lên nhánh main, ai sửa gì thì commit nấy. Mọi thứ ổn cho tới ngày hai người cùng sửa một file, một bản deploy mang theo tính năng chưa xong, hoặc không ai nhớ vì sao dòng code này lại tồn tại. Một quy trình Git rõ ràng không cần phức tạp, chỉ cần đủ để cả nhóm làm việc song song mà không giẫm chân nhau. Dưới đây là quy trình gọn nhẹ phù hợp với team từ ba đến mười người.

Chiến lược nhánh: giữ càng đơn giản càng tốt

Với team nhỏ, mô hình dựa trên một nhánh chính kèm các nhánh tính năng ngắn hạn, tương tự GitHub Flow, thường hiệu quả hơn các mô hình nhiều tầng như Git Flow.

  • main luôn ở trạng thái có thể deploy. Không ai push trực tiếp lên đây.
  • Nhánh tính năng được tách từ main cho mỗi đầu việc, sống trong vài ngày rồi được merge lại qua pull request.
  • Nếu cần môi trường staging, có thể thêm nhánh develop hoặc đơn giản deploy từng pull request lên môi trường preview.

Đặt tên nhánh theo một quy ước thống nhất giúp nhìn danh sách nhánh là biết ai đang làm gì:

feature/123-dang-nhap-google
fix/145-loi-tinh-tong-gio-hang
chore/cap-nhat-dependencies
docs/huong-dan-cai-dat

Kèm mã ticket trong tên nhánh giúp liên kết code với công việc trên Jira, Linear hay GitHub Issues. Quan trọng hơn cả: giữ nhánh ngắn hạn. Nhánh sống càng lâu, xung đột khi merge càng nhiều và càng khó review.

Viết commit message có ích cho người đọc sau

Commit message là nhật ký của dự án. Sáu tháng sau, khi lần theo một lỗi bằng git log hay git blame, bạn sẽ biết ơn những message rõ ràng. Một số quy tắc được cộng đồng thừa nhận rộng rãi:

  1. Dòng tiêu đề ngắn gọn, khoảng 50 ký tự, không chấm câu ở cuối.
  2. Viết ở thể mệnh lệnh: "Thêm", "Sửa", "Xóa" thay vì "Đã thêm".
  3. Cách một dòng trống giữa tiêu đề và phần thân.
  4. Phần thân giải thích vì sao thay đổi, vì cái gì thay đổi thì diff đã thể hiện.

Nhiều team áp dụng thêm chuẩn Conventional Commits, gắn tiền tố loại thay đổi vào đầu message:

feat(auth): thêm đăng nhập bằng Google
 
Người dùng doanh nghiệp yêu cầu SSO để giảm số mật khẩu phải nhớ.
Dùng OAuth 2.0, token lưu trong cookie httpOnly.
 
Refs: #123

Các tiền tố thường gặp gồm feat, fix, docs, refactor, test, chore. Lợi ích thực tế là bạn có thể tự động sinh changelog và tính số phiên bản theo semantic versioning, đồng thời lịch sử commit dễ lọc hơn hẳn.

Ngoài ra, mỗi commit nên là một thay đổi logic trọn vẹn. Tránh những commit kiểu "fix", "update" hay "wip" chứa cả chục thay đổi không liên quan. Nếu trong lúc làm bạn lỡ tạo nhiều commit vụn, hãy gộp lại trước khi mở pull request hoặc dùng tùy chọn squash khi merge.

Pull request: nơi chất lượng được kiểm soát

Pull request (PR) không chỉ là thủ tục để merge code mà còn là nơi chia sẻ kiến thức trong team. Một quy trình PR hiệu quả:

  1. Giữ PR nhỏ. PR vài trăm dòng được review kỹ; PR vài nghìn dòng thường chỉ được lướt qua rồi bấm duyệt.
  2. Mô tả rõ ràng. Nêu bối cảnh, thay đổi chính, cách kiểm thử, ảnh chụp màn hình nếu có thay đổi giao diện. Một PR template trong repo giúp mọi người không quên.
  3. Để CI chạy trước. Lint, kiểm tra kiểu và test tự động phải xanh trước khi nhờ người review, để reviewer tập trung vào logic thay vì dấu chấm phẩy.
  4. Yêu cầu ít nhất một người duyệt. Bật branch protection trên main để bắt buộc review và CI thành công.
  5. Phản hồi mang tính xây dựng. Bình luận vào code chứ không nhắm vào người viết; phân biệt rõ góp ý bắt buộc và gợi ý tùy chọn.
  6. Merge rồi xóa nhánh. Sau khi merge, xóa nhánh tính năng để danh sách nhánh luôn gọn.

Về cách merge, nhiều team nhỏ chọn squash and merge để mỗi PR trở thành một commit trên main, giúp lịch sử tuyến tính và dễ revert. Nếu team đã có kỷ luật commit tốt, rebase and merge giữ được chi tiết từng commit. Điều quan trọng là cả nhóm thống nhất một cách.

Thói quen nhỏ giúp tránh rắc rối lớn

  • Cập nhật nhánh của mình với main thường xuyên thay vì đợi tới lúc merge.
  • Không commit file bí mật như .env; khai báo chúng trong .gitignore ngay từ đầu.
  • Dùng tag để đánh dấu các bản release, giúp rollback nhanh khi cần.
  • Ghi quy trình vào file CONTRIBUTING.md để thành viên mới bắt nhịp nhanh.

Kết luận

Một Git workflow tốt cho team nhỏ dựa trên ba trụ cột: nhánh ngắn hạn tách từ một main luôn ổn định, commit message giải thích được lý do thay đổi và pull request nhỏ, có review cùng kiểm tra tự động. Đừng cố áp dụng quy trình phức tạp của các tổ chức lớn. Hãy bắt đầu đơn giản, ghi lại thành quy ước chung và điều chỉnh dần khi team lớn lên.

Nguồn tham khảo