Branching Model

Automatically building and testing every change, so integration problems surface immediately.

Systems tend to reproduce the communication structure of the organization that built them.

The Git state in which the current checkout points directly at a commit rather than a branch, harmless for looking around but a trap for new work, since commits made there belong to no branch and can quietly disappear.

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.

A branch created to develop one change in isolation before merging it back, a workflow that keeps the main line stable but grows riskier the longer the branch lives, since its divergence from everyone else's work compounds.

An urgent fix shipped outside the normal release flow, how teams branch and backport it, and why the healthiest hotfix process is the normal process run fast.

Validating changes against the state they will actually merge into, in order, rather than in isolation.

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

Shipping on a fixed schedule whether or not a given feature is ready, so features that miss one release simply wait for the next instead of holding everyone back.

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

A chain of dependent changes, each reviewed separately and merged in order.

Everyone integrating into one shared branch continuously, with short-lived feature branches.

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