The commit graph
The lanes beside the history, and what they are telling you.
Beside the list of commits, Innesta draws the graph: a lane per line of
development, and the merges between them.
The graph is drawn rather than borrowed, and the reason is legibility. A repository with eight active branches produces a picture that is either readable or a bowl of spaghetti depending entirely on how lanes are assigned.
Innesta’s rule is that a line of development keeps its lane: a commit hands its lane on to its first parent whenever that lane is free, so following one line down the picture means following one column. A lane is given up as soon as nothing is waiting in it, and the next branch that needs one takes the leftmost that is free — which is why the picture stays as narrow as the number of lines actually running at that point in the history.
What to read from it
- A branch point — one lane becoming two.
- A merge — two lanes becoming one. The commit at the join is the merge commit; it has two parents.
- A straight line where you might have expected a join — a rebase happened. Rebasing replays commits so that history is linear, which means the graph cannot show you that the work was done in parallel, because after a rebase it no longer looks as though it was.
Why merges and rebases look different
This is worth being clear about, because the graph is where the difference becomes visible.
Merging keeps the shape of what happened: two lines of work, joined. Rebasing keeps the history readable: one line, in order, as though the work had been done sequentially.
Neither is correct in general. The graph is how you see which one a repository has been using.