Atomic commit: mỗi commit chứa MỘT logical change hoàn chỉnh — pass tests độc lập, có thể revert độc lập, message mô tả đủ ý.
Tại sao commit "fat" là anti-pattern:
1. Revert nightmare: cần revert chỉ navbar fix nhưng buộc phải revert cả auth + deps update
2. git bisect bị nhiễu: khi tìm regression, mỗi commit nên là one thing — commit fat khó xác định cái gì gây bug
3. Code review khó: reviewer phải context-switch giữa auth logic, CSS, và package.json
4. git blame vô nghĩa: blame trên navbar file thấy commit "add user auth" → confusing
Ví dụ tách đúng:
git add src/auth/ && git commit -m "feat(auth): implement JWT authentication"
git add src/navbar/ && git commit -m "fix(navbar): correct mobile menu z-index"
git add package.json && git commit -m "chore(deps): upgrade react to 18.3.1"Trick: git add -p (patch mode) — interactive staging theo từng hunk, không phải toàn bộ file.
Cho phép tách 1 file có nhiều thay đổi thành nhiều commits.
Atomic commit: each commit contains ONE complete logical change — passes tests independently, can be reverted independently, the message fully describes the change.
Why fat commits are an anti-pattern:
1. Revert nightmare: need to revert only the navbar fix but are forced to revert auth + deps update too
2. git bisect noise: when hunting a regression, each commit should be one thing — fat commits make it hard to identify what caused the bug
3. Hard code review: reviewer must context-switch between auth logic, CSS, and package.json
4. git blame becomes meaningless: blame on a navbar file shows "add user auth" → confusing
Correct split example:
git add src/auth/ && git commit -m "feat(auth): implement JWT authentication"
git add src/navbar/ && git commit -m "fix(navbar): correct mobile menu z-index"
git add package.json && git commit -m "chore(deps): upgrade react to 18.3.1"Trick: git add -p (patch mode) — interactively stage by hunk, not entire file.
Lets you split one file with multiple changes into separate commits.