Kelly Mears

Atomic Commit

A commit containing exactly one logical change, complete and independently sound.

Version Control & Delivery1 min read197 words15 out · 16 in
also calledLogical commit

An atomic commit contains one logical change: complete enough to build and pass its checks on its own, small enough that its message describes all of it. It is the unit that makes history usable rather than merely present.

Three capabilities depend on it. Revert — backing out one change without unpicking unrelated work. Bisection — finding the first bad revision requires every revision to be independently sound, so a commit that is red on its own breaks the search. Review — a reviewer reading a sequence of scoped commits can follow the reasoning; a reviewer reading one large commit reads a diff.

The practical habit is to commit as each logical unit completes rather than accumulating everything into one change at the end. A change that fixes a bug, adds a test, updates documentation, and reformats an adjacent file is four commits, and each is independently reviewable.

Two notes for shared working copies. Stage by explicit path — a bulk add captures other people's uncommitted work. And when a fix belongs to an earlier commit in a sequence, folding it in rather than appending it keeps the earlier commit sound, which is the property bisection needs.

See also15

Commit

A recorded snapshot of a project with a message explaining it.

Version Control & Delivery23 connections

Conventional Commits

A lightweight convention giving commit messages a machine-readable type and scope.

Version Control & Delivery14 connections

Regression

A previously working behavior that a change has broken.

Method23 connections

Squash Merge

Collapsing a branch's commits into one before merging, trading granularity for a clean main history.

Version Control & Delivery24 connections

Code Review

A second person reading a change before it lands, and the practices that make it worth the time.

Version Control & Delivery38 connections

Provenance

The recorded origin of a change or a claim — who made it, when, and on what evidence.

Method44 connections

Version Control

A system recording the history of a project's files, enabling branching, merging, and recovery.

Version Control & Delivery26 connections

Pull Request

A proposal to merge a branch, carrying review, automated checks, and the discussion around it.

Version Control & Delivery25 connections

Plausible Mechanism

A causal explanation that was inferred rather than tested, and reads as more rigorous for being specific.

Method63 connections

Staging Area

The intermediate snapshot in Git between the working files and the next commit, which lets a developer choose exactly which changes go into each commit, down to individual lines.

Version Control & Delivery15 connections

Atomic File Write

Replacing a file so that readers and crashes see either the complete old version or the complete new one, never a half-written mix, by writing a temporary file and renaming it over the original.

Systems & Tooling12 connections

Git Bisect

Finding the commit that introduced a bug by binary search through history, testing the midpoint between a known-good and a known-bad version until one commit remains.

Testing & Verification17 connections

Git Blame

Showing, for every line of a file, the commit and author that last changed it, the starting point for finding out why code is the way it is.

Version Control & Delivery12 connections

Fast-Forward Merge

The two basic ways Git joins branches, by sliding a branch pointer forward or by recording a new commit with two parents, and how the choice shapes a project's history.

Version Control & Delivery14 connections

Diff

The listing of changes between two versions of a file, the algorithms that compute it, and the unified format that code review, patches, and merges are built on.

Version Control & Delivery13 connections

Linked from16