Merge Train

Server-side rules that stop people from pushing straight to important branches, requiring reviews, passing checks, and intact history instead.

The convention governing what branches exist, what they mean, and how work reaches production.

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

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.

Overlapping changes that a merge cannot combine automatically, requiring a decision.

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

Replaying a branch's commits onto a new base, producing new commits with the same changes.

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.

Two changes that merge cleanly and are incompatible in meaning.

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

Running only the tests a change could plausibly affect, using dependency graphs, coverage maps, or learned models, so large suites stay fast without giving up their safety net.

Combining two lines of work by comparing both against their common ancestor.

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