Trunk, Branch and Merge Explained

The history graph: trunk in one line, branches forking off, merges as extra edges — and why history is not a tree.

The trunk is the main line of a project's history: the longest continuous sequence of commits, and the line that releases are usually built from. A branch forks from the trunk at a single point and carries its own commits; branches let one line of work fix bugs while another adds features.

A merge rejoins the lines. On the graph it appears as an edge with two incoming lines and one outgoing node — the extra edge that makes history a graph rather than a tree. A tree allows exactly one path from the root to any node; a merged history allows several.

This shape has consequences for reading history. A revision with two parents means "the previous revision" is no longer unique, so a comparison or a restore must decide which line it follows. Renaming, splitting or merging files adds a second ambiguity: identity itself becomes a question revision tracking must resolve.

Comparisons and restores work off this graph. Two nodes are picked, the lines between them are compared, and the differences are shown; a restore pulls an older revision forward into the working copy. With some types of files, two sets of changes can also be merged automatically rather than compared by hand.

The visual test is simple: if a line in the graph has more than one line feeding into a node, that node is a merge; if a line runs continuously with one parent per commit, that stretch is trunk or a branch — the trunk being the longest such line in the project.

• Trunk: the longest continuous line of commits.
• Branch: a forked line with its own commits.
• Merge: an edge with two incoming lines and one outgoing node.
• Graph, not a tree: merges create extra edges.
• Comparisons and restores pick two nodes and work between them.

Further reading

• Version Control Systems, 1972 to 2005
• Your First Commit and Branch, Step by Step