#git bot interface

.gitgraph A B C

.gitgraph A B C;
D E F[mergeto C]

My first merge, yay!

.gitgraph A B C;;
D E F[mergeto C]

More spacing because the empty definition starts a cluster.

.gitgraph A B C;;
D E F[mergeto C];
align A D

Maybe we want to align the two root commits at the same level...

.gitgraph A B C[branch master?];;
A' B' C'[branch master]

Three new features at once!

• We add branch labels to some commits.
• The question mark dims a commit or pretty much anything, typically to show an old version/state.
• A and A' are automatically linked to visualize commit rewriting, e.g. rebases.

The cluster split (;;) helps the layouting – in this case it helped Graphviz render the two histories in the correct order. However, this is a little hit-and-miss.

.gitgraph A B C[tag v0.1 remote origin/master]

We can do some other types of references, too.

.gitgraph A B C[branch master remote origin/master];
  HEAD? master;
  symref FETCH_HEAD origin/master;;
A D E[branch test];
  HEAD test

New lessons:

• We can draw a dimmed HEAD and a proper one; easy!
• HEAD is a special case of a symbolic ref; the "symref" keyword is needed if you want to draw symbolic refs with other names.
• Two series of commits can share commits. The first usage determines where it is rendered. Generally you can reuse commit names virtually everywhere.
• It really pays off putting any related refs in the same cluster. Experiment with putting the ;; in any different place and you'll see what I mean.

.gitgraph A[label "I like really long commit titles"] B C;
A D E

If you want to make a commit description super verbose, you can put it as a label and still reuse the commit's original name in other parts of the definition.

.gitgraph A[color red] B[color green] C[color yellow]
D[color blue];
E[c orange] F[c cyan] G[c pink] H[c violet];
I[c gold] ...[c silver] K[c bronze]

Did someone say colours? (The full list of abbreviations is in the grammar at the bottom.)

.gitgraph A B;
  merge C B ... X[label ...];
  edge C X label "this history is boring" dashed;;
F; G; edge G F

Thought I didn't have you covered with exotic features like octopus merges? Hah, think again.

Also, notice how I can just "make up" commits as children for the merge and they will be auto-created. Whenever you mention a commit somewhere that isn't part of a sequence, it will be created as an (otherwise) unlinked commit, until you do something else that links it up.

You noticed the elliptical commits, I'm sure. Basically you can use "..." once to automatically create a differently-rendered fake commit that suggests that there are more commits than the graph shows. If you want to use it a second time, well, two commits can't have the same name, hence the label trick which achieves the same look.

Finally, you can use the "edge" command to add a label to an existing edge. It will not automatically create a new edge, though, as can be seen in the right part of the example. (We can also style edges using the keywords "dashed", "dim" and "dotted".)

Attempt 1:

.gitgraph A B C[branch origin/master?] D? E? F?[branch master?];
C G H I[branch origin/master];
I D' E' F'[branch master]

This looks a little chaotic, doesn't it? How can we fix that? Well, ideally D-F and D'-F' would be aligned on the same level, right? Let's try that next...

Attempt 2:

.gitgraph A B C[branch origin/master?] D? E? F?[branch master?];
C G H I[branch origin/master];
I D' E' F'[branch master];
align D? D'

Wow, that's even worse! (Spoiler: if we repeat the same for E and F, it doesn't get much better...)

Fortunately there's a different approach if we take a step back. We told Graphviz that D should be above C (due to the arrow between them) and D' should be above I. Can't we tell it that D should be above I, too? Yes we can! Let's check it out:

Attempt 3:

.gitgraph A B C[branch origin/master?] D? E? F?[branch master?];
C G H I[branch origin/master];
I D' E' F'[branch master];
up I D?

Say, that looks quite decent. Let's stick with this one.