Git cho dự án nhóm: commit, branch, rebase và cứu sự cố Trung cấp

Trang này là bản đồ của cụm Git: mỗi phần trả lời câu hỏi gì, đọc theo thứ tự nào, và mặc định nên chọn gì.

Vấn đề

Ba tháng sau release, production tính sai giá. git log có 40 commit tên fix, wip, update, và một commit 3.000 dòng trộn refactor với đổi logic. revert thì mất luôn tính năng khác, bisect vô dụng vì nửa số commit không build được.

Git không làm hỏng dự án. Thói quen dùng Git mới làm. Cụm này gom các quy tắc để lịch sử commit thành công cụ debug, không phải bãi rác.

Đọc theo luồng nào

Đang tải diagram…

Trong cụm này

Phần	Câu hỏi nó trả lời
Commit message & atomic commit	Viết message thế nào? Một commit nên chứa gì?
Branch, merge, rebase	Trunk-based hay GitFlow? Merge, rebase hay squash? Force push an toàn ra sao?
Cứu sự cố	Lỡ reset --hard, push bug lên main, cần tìm commit gây bug — dùng lệnh gì?
Secret, PR và checklist	Lộ secret thì làm gì trước? PR bao lớn là vừa? Review gì?
Lỗi hay gặp	Các lệnh/thói quen sai phổ biến, đặt cạnh cách đúng

Tóm tắt quyết định

Câu hỏi	Mặc định nên chọn	Lý do
Commit message	Conventional Commits, subject ≤ ~50 ký tự, mệnh lệnh	Đọc được bằng git log --oneline, sinh changelog và SemVer tự động
Kích thước commit	Atomic: một thay đổi logic, build và test pass	revert, cherry-pick, bisect hoạt động được
Branching	Trunk-based, branch sống ngắn (≤ 1-2 ngày) + feature flag	Ít conflict, CI phản ánh đúng trạng thái main
Merge PR	Squash merge cho PR nhỏ; merge commit khi PR gồm commit có chủ đích	Một PR = một commit dễ revert
Đồng bộ branch của mình	git rebase origin/main khi branch chỉ mình bạn dùng	Lịch sử thẳng, không có merge commit rác
Push sau rebase	--force-with-lease, không bao giờ --force	Không ghi đè commit người khác vừa push
Sự cố trên main	git revert, không reset + force push	Không rewrite lịch sử người khác đang dùng
Lỡ lộ secret	Rotate trước, rewrite history sau	Bản sao, fork, cache đã có secret; rewrite không thu hồi được

Tóm tắt

• Commit là đơn vị để revert, cherry-pick, bisect — viết atomic và tách refactor khỏi thay đổi hành vi.
• Conventional Commits: feat/fix bắt buộc đúng nghĩa, breaking change bằng ! hoặc BREAKING CHANGE:; subject ngắn, body nói vì sao.
• Trunk-based / GitHub flow với branch ngắn và feature flag là mặc định cho web service; GitFlow cho phần mềm nhiều version.
• Chỉ rebase commit chưa ai dựa vào; force push luôn bằng --force-with-lease.
• Đã push lên branch chung thì revert; chưa push thì reset/restore; mất commit thì reflog; tìm bug thì bisect run.
• Lộ secret: rotate trước, rewrite history sau — rewrite không thu hồi được bản sao đã tồn tại.

Tự kiểm tra:

1. Bạn vừa reset --hard mất 3 commit chưa push — lệnh nào cứu được, và nó có cứu được file chưa từng git add không?
2. Vì sao --force-with-lease có thể mất tác dụng khi IDE tự git fetch?
3. Script cho git bisect run nên trả exit code gì khi project không build được ở commit đang thử?
4. Commit feat(api)!: bỏ field legacyId sẽ tăng phần nào của SemVer?

Tiếp theo: Commit message & atomic commit.