Commit early, commit often

"Commit early, commit often" is a software development [principle] that encourages developers to save their work to a version control repository in many small increments, rather than holding a large body of changes back until a feature or task is finished.

Each commit records a single, self-contained step – a bug fix, a refactor, a slice of a feature – as a discrete snapshot that can be reviewed, reverted, or cherry-picked independently. Frequent commits turn version control into a safety net. When a change goes wrong, you lose minutes of work rather than hours, and you can step back to a known-good state with confidence.

The principle is closely related to continuous integration, the practice of integrating code into a shared repository multiple times a day. Frequent commits are the granular mechanism that makes continuous integration tractable. They also underpin trunk-based development, whose "never break the build" rule is satisfied by committing small, well-tested increments to the mainline branch.

Large, infrequent commits carry the opposite risks. A single sprawling commit is harder to review, more likely to produce merge conflicts, and harder to roll back piecemeal if part of it is wrong. They also delay feedback. Problems lurk in a long-lived branch until it is finally integrated, by which point the cost of fixing them has grown.

The aphorism resonates with the values of extreme programming, which advocates continuous, incremental progress over large, phased deliverables.

Important

Committing often does not mean committing broken code. Each commit should leave the codebase in a buildable, tested state, so that any commit can serve as the base for further work or as a rollback target.

See also