Three-Way Merge

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

Copying the change from one commit onto another branch as a new commit, the standard way to backport a fix without merging everything else that came with it.

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

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

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.

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.

Git stores every version of a project as a graph of immutable objects named by the hashes of their contents, blobs for files, trees for directories, and commits for snapshots, which makes history tamper-evident and identical content free to store twice.

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

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

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

Two changes that merge cleanly and are incompatible in meaning.

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.