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.