Chọn mô hình Git Branching đơn giản

Đối với dự án nhóm đầu tiên, hãy giữ mô hình branching ở quy mô nhỏ: main luôn ở trạng thái có thể deploy, và mỗi nhiệm vụ có một feature branch tồn tại trong thời gian ngắn. Nếu nhóm đang xây dựng một landing page bằng React và một checkout API, phần công việc có thể nằm trong feature/pricing-page và feature/create-checkout-session thay vì cùng nằm trong một development branch dùng chung. Sự tách biệt này cho phép hai developer làm việc song song mà không trộn lẫn code chưa hoàn thiện. Tránh thêm các branch develop, release hoặc hotfix cho đến khi dự án có một quy trình release thực tế cần đến chúng.

Hãy thống nhất quy trình trước khi ticket đầu tiên bắt đầu. Ghi rõ rằng main chỉ nhận thay đổi thông qua pull request, các feature branch được tạo từ main và các branch đã merge sẽ bị xóa. Ví dụ, một nhiệm vụ đặt lại mật khẩu nên đi theo quy trình từ issue đến feature branch, rồi review và cuối cùng là main, không push trực tiếp vào branch dùng chung. Những quy tắc này biến việc quản lý phiên bản thành một thói quen nhóm dễ dự đoán, thay vì một tập hợp các sở thích cá nhân.

Thiết lập quy tắc cho Main và cách đặt tên Branch

Bảo vệ main trong phần cài đặt repository trước khi bất kỳ ai mở pull request. Yêu cầu các kiểm tra tự động phải đạt và cần ít nhất một lượt phê duyệt, đồng thời chặn force push để một sai sót cục bộ không thể viết lại lịch sử dùng chung của nhóm. Với nhóm bốn người, yêu cầu một reviewer thường là điểm khởi đầu thực tế; hãy tăng yêu cầu này đối với code thanh toán hoặc xác thực nhạy cảm. Giữ quy tắc này trong CONTRIBUTING.md để thành viên mới có thể làm theo mà không cần hỏi riêng.

Sử dụng tên branch thể hiện mục đích và, nếu có, kèm theo ID của task. Ví dụ gồm feature/42-reset-password, fix/57-cart-total, docs/api-setup và chore/update-node. Tên viết thường với dấu gạch nối giúp dễ quét hơn trong đầu ra của terminal và danh sách pull request so với các tên như John'sNewBranch hoặc work. Hãy xóa branch sau khi merge để danh sách remote phản ánh công việc đang hoạt động, thay vì tích lũy các thử nghiệm bị bỏ dở suốt nhiều tháng.

Bắt đầu Feature từ Main đã được cập nhật

Trước khi lập trình, hãy đồng bộ với remote và tạo feature branch từ nhánh main hiện tại. Chạy `git switch main`, sau đó `git pull --ff-only origin main`, rồi tạo nhánh bằng `git switch -c feature/42-reset-password`. Tùy chọn `--ff-only` ngăn Git âm thầm tạo một merge commit ngoài dự kiến trong quá trình cập nhật này. Bắt đầu từ một base mới nhất sẽ giảm khả năng một công việc kéo dài ba ngày lập tức xung đột với thay đổi đã được merge vào ngày hôm qua.

Kiểm tra tên nhánh và điểm bắt đầu bằng `git status` và `git log --oneline --decorate -5` trước khi chỉnh sửa tệp. Nếu task đã có branch hiện hữu, trước tiên hãy fetch bằng `git fetch origin` và so sánh branch đó với `origin/main` thay vì tạo một branch thứ hai có tên tương tự. Với branch chậm hơn một commit, bạn có thể cập nhật bằng `git rebase origin/main` sau khi xác nhận các thay đổi cục bộ đã được commit. Không rebase một branch mà nhiều thành viên trong nhóm đang sử dụng tích cực, trừ khi cả nhóm đã thống nhất về việc viết lại lịch sử kết quả.

Tạo các Git commit nhỏ, dễ review

Hãy tạo các commit đủ nhỏ để một lập trình viên khác có thể hiểu từng thay đổi trong vòng một hoặc hai phút. Một tính năng checkout có thể dùng một commit cho database migration, một commit cho endpoint và một commit cho form, trong khi một lỗi chính tả dài ba dòng thường nên để trong một commit duy nhất. Chạy các bài test liên quan trước mỗi lần push, vì một commit dễ review nhưng không vượt qua test suite hiện có vẫn làm chậm cả nhóm. Không đưa các tệp được tạo tự động, secret của môi trường cục bộ và các thay đổi format không liên quan vào branch.

Viết commit message ở thể mệnh lệnh, chẳng hạn như Add password reset validation hoặc Fix cart total rounding. Mỗi message nên giải thích mục đích, còn diff sẽ thể hiện chi tiết triển khai. Sau khi kiểm tra kết quả cục bộ, hãy publish branch mới bằng `git push -u origin feature/42-reset-password`. Nếu phát hiện lỗi trước khi review, hãy amend hoặc squash lỗi đó ở local; khi reviewer đã bắt đầu bình luận, nên tạo một corrective commit mới để cuộc thảo luận vẫn có thể truy vết.

Mở Pull Request và chạy CI

Hãy mở pull request ngay khi branch sẵn sàng để review, kể cả khi thay đổi chỉ liên quan đến sáu tệp. Đặt `main` làm target, liên kết task, mô tả những gì đã thay đổi và ghi lại chính xác lệnh validation, chẳng hạn như `npm test` và `npm run lint`. Với một thay đổi trên login form, hãy đưa vào route bị ảnh hưởng, hành vi bàn phím, screenshot của error state và mọi migration step mà reviewer cần chạy. Chỉ đánh dấu request là draft khi bạn muốn nhận phản hồi sớm trước khi yêu cầu phê duyệt.

Sử dụng continuous integration để chạy trên pull request cùng các quality gate mà team yêu cầu trên laptop của developer. Một pipeline ban đầu hữu ích có thể cài dependency, chạy unit test, chạy lint và build ứng dụng thành bốn bước riêng biệt, hiển thị rõ ràng. Nếu build thất bại vì bị thiếu tệp package-lock, hãy sửa branch và push lại thay vì yêu cầu reviewer bỏ qua check màu đỏ. CI là một tín hiệu, không phải sự thay thế cho review: một test có thể pass trong khi một button vẫn không thể truy cập hoặc response từ API làm lộ dữ liệu riêng tư.

Review, merge và duy trì main ổn định

Hãy xem các bình luận review là những thay đổi đối với thiết kế dùng chung, không phải là một cuộc bỏ phiếu về tác giả. Nếu reviewer yêu cầu validation phía server cho trường giá, hãy cập nhật code, thêm một test tập trung cho giá trị âm như `-1` và phản hồi bằng commit hoặc vị trí tệp. Giải quyết các câu hỏi trong pull request để lịch sử cuối cùng ghi lại lý do triển khai thay đổi. Hãy yêu cầu reviewer thứ hai khi bình luận đầu tiên cho thấy một mối quan ngại rộng hơn về bảo mật, mất dữ liệu hoặc hành vi của public API.

Chọn một chính sách merge và áp dụng nhất quán. Với dự án đầu tiên, việc squash merge một tính năng gồm năm commit thành một commit có nội dung mô tả rõ ràng sẽ giúp nhánh main dễ đọc, trong khi các nhóm cần tra cứu chi tiết lịch sử phát hành có thể giữ lại từng commit riêng lẻ. Chỉ merge sau khi các bước kiểm tra bắt buộc đều đạt, phê duyệt vẫn còn hiệu lực và nhánh không bị chậm hơn main theo quy định của repository. Sau khi merge, hãy thông báo mọi bước triển khai hoặc migration thủ công trước khi bắt đầu nhiệm vụ tiếp theo.

Giải quyết xung đột và dọn dẹp các nhánh

Khi main thay đổi trong lúc bạn đang làm việc, hãy cập nhật nhánh trước khi yêu cầu phê duyệt cuối cùng. Fetch remote, chạy git rebase origin/main và giải quyết xung đột từng tệp một; chẳng hạn, giữ lại component nút dùng chung mới nhất đồng thời bảo toàn hành vi checkout mới của bạn. Sau khi chỉnh sửa xung đột, chạy git add trên tệp đó và git rebase --continue, sau đó chạy lại các bài kiểm thử. Nếu xung đột trở nên khó hiểu, git rebase --abort sẽ đưa nhánh về trạng thái trước khi rebase để bạn có thể nhờ hỗ trợ mà không làm mất phần công việc đã commit.

Sau khi pull request được merge, hãy xóa nhánh remote bằng git push origin --delete feature/42-reset-password và xóa bản sao local bằng git branch -d feature/42-reset-password. Sau đó chạy git switch main và git pull --ff-only origin main trước khi chọn ticket tiếp theo. Nếu vẫn còn phần việc chưa hoàn thành, hãy tạo một nhánh mới từ main đã được cập nhật thay vì tiếp tục sử dụng nhánh đã merge. Sau một tuần, repository nên thể hiện một nhánh main ổn định, một nhóm nhỏ các nhiệm vụ đang thực hiện và lịch sử giải thích được từng thay đổi hướng đến người dùng.

Bài viết liên quan

Đọc thêm

Git

kiểm soát phiên bản

tích hợp liên tục