Overview
This page is the atomic definition. The deep-dive lives at git.
Definition
An atomic commit captures one logical change: one bug fix, one feature, or one refactor. The commit builds and passes tests on its own, and reverting it does not break unrelated code. Atomicity is the discipline that makes git bisect, code review, and rollback useful; a commit that mixes a typo fix with a schema migration is unbisectable. Atomicity does not constrain commit size; a 500-line atomic refactor is fine if every line belongs to the same logical change.
When it applies
Apply atomicity to every commit on shared branches. Squash work-in-progress commits before merging so the long-term history is atomic.
Example
Two changes land as two commits:
refactor(auth): extract token-validation helperfix(auth): reject expired tokens at the edge
Combining them in one commit would hide the fix inside the refactor, making it hard to bisect when a regression appears later.
Related concepts
- git - the deep-dive on commit hygiene.
- conventional-commits - the message format that pairs with atomic commits.
- git-commands - the commands for staging, squashing, and bisecting.
- github - PR review reads atomic commits one at a time.
- general-principles - the broader principles that motivate atomicity.
Citing this term
See Atomic commit (llmbestpractices.com/glossary/atomic-commit).