Git workflow chuyên nghiệp: commit sạch, branch rõ, review dễ

Git là công cụ giao tiếp của team#

Git không chỉ để lưu lịch sử code. Một lịch sử Git sạch giúp reviewer hiểu thay đổi, giúp người sau debug bằng git blame, giúp release manager biết commit nào đang ở production và giúp bạn rollback chính xác khi có lỗi. Ngược lại, commit lộn xộn làm mọi thao tác sau đó tốn thời gian hơn.

Mục tiêu của Git workflow không phải là tuân thủ nghi thức phức tạp, mà là tạo ra lịch sử thay đổi dễ đọc, dễ review và ít xung đột.

Commit nên kể một câu chuyện nhỏ#

Một commit tốt có phạm vi hẹp và trạng thái build được. Nếu commit vừa sửa UI, vừa đổi schema, vừa format toàn repo và vừa đổi logic auth, reviewer khó hiểu và rollback cũng rủi ro. Hãy tách commit theo ý nghĩa thay đổi.

• Commit 1: thêm migration hoặc schema.
• Commit 2: thêm service/repository xử lý logic mới.
• Commit 3: nối API hoặc UI vào logic.
• Commit 4: thêm test và chỉnh tài liệu nếu cần.

Message nên nói vì sao hoặc thay đổi gì ở mức có ích. fix bug không giúp gì nhiều. fix post visibility for future published_at cho người đọc biết rõ vấn đề hơn.

Branch strategy đừng phức tạp quá sớm#

Với nhiều team hiện đại, trunk-based development hoặc GitHub flow là đủ: branch ngắn sống, mở pull request, review, CI pass rồi merge vào main. Git Flow với nhiều nhánh develop, release, hotfix có thể phù hợp sản phẩm release theo phiên bản dài, nhưng với web app deploy liên tục, nó thường tạo thêm ceremony.

• main: luôn có thể deploy hoặc gần deploy được.
• feature branch: sống ngắn, tập trung một mục tiêu.
• pull request: nơi review design, code, test và rủi ro deploy.
• tag/release: đánh dấu artifact đã phát hành.

Branch sống càng lâu, xác suất conflict và lệch kiến trúc càng cao. Hãy merge thường xuyên hoặc chia feature lớn thành các phần nhỏ có thể review độc lập.

Rebase, merge và squash dùng khi nào?#

merge giữ lại lịch sử nhánh và tạo merge commit. rebase đặt commit của bạn lên đầu base mới để lịch sử tuyến tính hơn. squash gom nhiều commit thành một commit khi merge. Không có lựa chọn nào luôn đúng; team cần thống nhất.

• Dùng rebase trên branch cá nhân để cập nhật với main trước khi mở PR hoặc trước khi merge.
• Không rebase branch chung có nhiều người đang dựa vào nếu chưa thống nhất.
• Dùng squash khi lịch sử commit trong PR chỉ là các bước thử nghiệm không cần giữ.
• Dùng merge commit khi muốn giữ ngữ cảnh một feature branch lớn.

git fetch origin
git switch feature/post-editor
git rebase origin/main
git push --force-with-lease

--force-with-lease an toàn hơn --force vì nó từ chối ghi đè nếu remote đã có thay đổi mới mà local của bạn chưa biết.

Giải quyết conflict có phương pháp#

Conflict không phải lỗi nghiêm trọng. Nó chỉ nói rằng Git không thể tự quyết định cách kết hợp hai thay đổi. Đừng vội chọn toàn bộ "ours" hoặc "theirs" nếu chưa hiểu logic. Hãy đọc cả hai phía, xem commit liên quan và chạy test sau khi resolve.

git status
git diff
git log --oneline --decorate --graph --all -20
git add src/app/api/posts/route.ts
git rebase --continue

Nếu conflict quá khó, hãy giảm phạm vi: resolve từng file, chạy test nhỏ, commit hoặc continue, rồi sang file tiếp theo. Với conflict ở lockfile, thường nên regenerate bằng package manager sau khi package manifest đã đúng.

Pull request tốt giúp reviewer tiết kiệm thời gian#

Một PR nên có mô tả ngắn về mục tiêu, ảnh hưởng chính, cách test và rủi ro. Đừng bắt reviewer tự suy luận từ diff. Nếu thay đổi có migration, breaking change hoặc ảnh hưởng security, hãy nói rõ.

• What: thay đổi gì.
• Why: vì sao cần thay đổi.
• Test: đã chạy command nào, case nào chưa test được.
• Risk: phần nào cần reviewer chú ý hơn.

Reviewer không chỉ tìm lỗi cú pháp. Reviewer kiểm tra behavior, edge case, bảo mật, performance, khả năng maintain và sự phù hợp với kiến trúc hiện tại.

Những command Git nên dùng thành thạo#

git status
git diff
git diff --staged
git log --oneline --graph --decorate
git switch -c feature/name
git restore src/file.ts
git restore --staged src/file.ts
git cherry-pick commit_sha
git revert commit_sha
git bisect start

git revert thường an toàn hơn xóa lịch sử trên nhánh shared vì nó tạo commit đảo ngược thay đổi. git bisect cực kỳ hữu ích khi cần tìm commit gây lỗi trong một khoảng lịch sử dài.

Quy tắc an toàn khi làm việc với Git#

• Luôn kiểm tra git status trước khi pull, rebase, reset hoặc switch branch.
• Không dùng reset --hard nếu chưa chắc dữ liệu local không cần giữ.
• Không force push lên branch người khác đang dùng nếu chưa trao đổi.
• Commit file lock khi dependency thay đổi.
• Không commit secret, token, file env hoặc dữ liệu khách hàng.
• Giữ PR nhỏ hơn mức reviewer có thể đọc kỹ trong một phiên.

Git workflow chuyên nghiệp không làm bạn chậm lại. Nó giảm thời gian review, giảm lỗi merge và giúp mỗi thay đổi có dấu vết rõ ràng. Đó là nền tảng của một team engineering trưởng thành.

Nguồn tham khảo chính#

• Git Docs: git rebase
• Git Docs: git push
• Git Docs: git bisect