Letm Blog

Quản lý một Git repository có nhiều developer cùng làm việc

collaboration , Git , repository management. , software development , team management

Quản lý một Git repository khi có nhiều developer cùng làm việc giống như việc điều phối giao thông vậy: không có luật lệ và quy trình rõ ràng thì chắc chắn sẽ xảy ra “tai nạn” (xung đột code - vỡ trận repo).

Để dự án chạy mượt mà, bạn cần áp dụng một chiến lược quản lý chuẩn chỉnh dưới đây:

1. Chọn một Git Workflow (Mô hình phân nhánh) phù hợp

Đây là bước quan trọng nhất để mọi người biết mình phải tạo nhánh (branch) từ đâu và merge (hợp nhất) vào đâu.

  • GitHub Flow (Đơn giản, phù hợp với CI/CD, dự án nhỏ/vừa):

  • Chỉ có một nhánh chính là main (hoặc master).

  • Mỗi khi làm tính năng mới, dev sẽ tạo nhánh từ main (ví dụ: feature/login).

  • Xong việc thì tạo Pull Request (PR) để mọi người review, sau đó merge thẳng vào main.

  • Gitflow (Chặt chẽ, phù hợp với dự án lớn, release theo phiên bản):

  • main: Chứa code sản phẩm (production-ready).

  • develop: Nhánh chính để các dev tích hợp code hàng ngày.

  • feature/*: Nhánh làm tính năng mới (tách từ develop).

  • release/* và hotfix/*: Nhánh để chuẩn bị đóng gói hoặc sửa lỗi gấp.

2. Quy trình làm việc bắt buộc qua Pull Request (PR) / Merge Request (MR)

Tuyệt đối cấm việc dev tự ý push (đẩy) code trực tiếp vào các nhánh chính như main hay develop.

  • Bật tính năng Protected Branches: Trên GitHub/GitLab, hãy khóa nhánh main/develop lại. Chỉ cho phép merge thông qua PR và sau khi đã được phê duyệt.
  • Code Review (Đánh giá code): Yêu cầu ít nhất 1 hoặc 2 dev khác vào đọc, nhận xét code trước khi cho phép merge. Việc này giúp phát hiện lỗi sớm và giữ chất lượng code đồng đều.

3. Quy tắc “Ăn dặm” hàng ngày (Giao tiếp với Remote Repo)

Để giảm thiểu tối đa việc bị Conflict (Xung đột code) khi nhiều người cùng sửa một file, hãy bắt các dev tuân thủ:

  • Pull thường xuyên: Trước khi bắt đầu viết code và trước khi tạo PR, dev phải git pull code mới nhất từ nhánh chung về máy mình.
  • Chia nhỏ Commit và PR: Đừng gom cả một tính năng khổng lồ làm trong 2 tuần vào 1 PR. Hãy chia nhỏ ra thành các task làm trong 1-2 ngày để dễ review và dễ merge.
  • Giải quyết conflict ở Local: Nếu xảy ra conflict khi làm PR, dev phải tự kéo code mới về máy mình (git merge hoặc git rebase nhánh chính vào nhánh feature), tự fix conflict dưới máy mình trước rồi mới push lại lên remote.

4. Chuẩn hóa Commit Message và Cách đặt tên nhánh

Khi có hàng chục commit mỗi ngày, nếu ai thích ghi gì thì ghi (kiểu: “fix bug”, “done”, “asdasd”) thì lịch sử repo sẽ thành một bãi rác.

  • Áp dụng Conventional Commits: Quy định commit phải có cấu trúc rõ ràng:

  • feat: thêm chức năng đăng nhập bằng Google

  • fix: sửa lỗi giao diện nút bấm trên Safari

  • docs: cập nhật tài liệu hướng dẫn cài đặt

  • Đặt tên nhánh có quy ước: Ví dụ: loại-nhánh/mã-task-tên-tính-năng (feature/JIRA-123-login-page, bugfix/JIRA-456-fix-api-crash).

5. Tự động hóa với CI/CD (Lớp bảo vệ cuối cùng)

Đừng chỉ tin vào mắt người, hãy để máy móc kiểm tra code hộ bạn. Hãy thiết lập các công cụ CI (GitHub Actions, GitLab CI, Jenkins…) để tự động chạy mỗi khi có ai đó tạo PR:

  • Linter & Formatter: Ép code phải viết đúng chuẩn format của dự án (thừa dấu cách, thiếu dấu chấm phẩy là fail CI, không cho merge).
  • Automation Tests: Tự động chạy các bài test (Unit test, Integration test). Nếu code mới làm hỏng tính năng cũ (test fail) -> Khóa nút merge ngay lập tức.