intermediate
Atomic commits
Group one logical change per commit so review, revert, cherry-pick, and bisect remain effective.
An atomic commit groups one coherent change with its tests and documentation. The commit should stand alone: reviewable, revertible, cherry-pickable, and explainable in one sentence.
# split mixed edits
git add -p src/auth.ts
git commit -m "fix(auth): reject expired refresh tokens"
git add -p src/auth.ts
git commit -m "refactor(auth): extract token parser"
Separate refactors from behavior changes when possible — reviewers and `git bisect` depend on that boundary.
On interviews: patch staging, splitting a large branch before PR, how atomic commits help incident revert and release notes.
Common pitfalls: one commit mixing feature + unrelated fix + format; microscopic commits that add review noise without clarity.
The trade-off is commit count versus logical independence — optimize for the next debugger, not minimal SHA count.
Checklist:
- One logical change per commit.
- Include tests with behavior in the same commit.
- Separate mechanical edits from semantic edits.
- Use interactive staging to split work.