As far as I can tell, the term \"branch\" (in Git parlance) may refer to related but different things:
You are correct.
We can further split your item 1 by separating "local" and "remote" branch labels: local branches (local labels) are names that start (internally—many front-end command hide this) with refs/heads/
, while "remote branches"—which are also called "remote-tracking branches"—start with refs/remotes/
and then have one more path component naming the specific remote before the part naming the branch. (Edit, April 2018: I dislike the phrase "remote branch" or "remote-tracking branch"; I think it's better to just call these remote-tracking names. But there is a lot of existing documentation that uses the other two phrases, so we need to be aware of this usage.)
For instance, you are no doubt familiar with refs/remotes/origin/master
, but if you have a remote named bob
you might also have refs/remotes/bob/hacks/feep
that tracks Bob's hacks/feep
.
A local branch name refs/heads/branch
has the distinguishing feature that git checkout
will put you "on" that branch by default, by writing that name into the special HEAD
reference; and once it you are set up this way, new commits (created by git commit
, git merge
, git cherry-pick
, etc.) cause the new commit's SHA-1 to be written into the branch-file. (The new commit has as its parent, or one of its parents, the old tip-of-branch.)
I have attempted to use terms like "branch tip" to denote specifically the commit to which a branch name like refs/heads/master
points, "branch name" or "local branch name" to refer to the name itself (whether prefixed by refs/heads/
or not), and—I think this is the least successful—"branch structure" to refer to the DAG subset. However, given a DAG with a fork-and-merge like this:
o--o
/ \
...-o--o o--o-...
\ /
o--o
I sometimes want to refer to one or the other half of the little benzene-ring-like object as "a branch" as well, and I have no really good term for this.
(Incidentally, if you were a topologist, the fact that the Atlassian diagram can also be drawn linearly would not bother you. However, as the old joke goes, topologists keep trying to drink out of their donuts and eat their coffee mugs since each one is just a torus.)
In the second case, we mean "the commits that are reachable from the commit pointed to by the branch".
In the Pro Git example, assuming the topic
branch points to commit C7
, that branch contains commits C7
, C6
, C5
, C4
, C3
, C2
, and C1
. There is no other notion of a commit being "on" a branch than this in Git, and you are correct that you could redraw the DAG linearly.
The Lynda.com diagram is terribly unclear, and I suspect you're right that it's misleading.