The main things that come to mind for having a local branch track another local branch are (1) more informed messages from Git regarding a branch being ahead/behind of the tracked branch and (2) trigger hooks.
One area Git displays more information is when creating a branch. Creating a basic branch looks like the following:
$ git co --track -b B master
Branch B set up to track local branch master.
Switched to a new branch 'B'
This would add the following in .git/config:
[branch "B"]
remote = .
merge = refs/heads/master
After committing some changes on branches A and B, executing git status -s -b on branch A displays ## A while on branch B it displays ## B...master [ahead 1, behind 1], providing some quick information regarding the relationship between branches B and master.
The other area where you might want a local branch track another local branch is to trigger hooks; in particular pre-receive, update, post-receive and post-update during a git push. You might have hooks to, for example, trigger a build on a continuous integration server, do some license header checks, check for white space format errors, etc.
Note that the ahead/behind information that you have between one branch 'B' and another 'A' tracked by the first only works if the branch.B.merge config is strictly defined: refs/heads/master.
It wouldn't work if it is loosely define: 'master'.
When checking out a branch that is set to build on top of another
branch (often, a remote-tracking branch), "git checkout" reports how
your work relates to the other branch, e.g.
Your branch is behind 'origin/master', and can be fast-forwarded.
Back when this feature was introduced, this was only done for branches that build on remote-tracking branches, but 5e6e2b4 (Make local branches behave like remote branches when --tracked, 2009-04-01, git 1.6.3) added support to give the same report for branches that build on other local branches (i.e. branches whose branch.*.remote variables are set to '.').
Unlike the support for the branches building on remote-tracking branches, however, this did not take into account the fact that branch.*.merge configuration is allowed to record a shortened branch name.
When branch.*.merge is set to 'master' (not 'refs/heads/master'), i.e. "my branch builds on the local 'master' branch", this caused "git checkout" to report:
Your branch is based on 'master', but the upstream is gone.
The upstream is our repository and is definitely not gone, so this
output is nonsense.
There are many occasions when tracking another local branch is useful. For example, in some git workflows, there something in place protecting master from directly receiving push requests. One example is a code review or continuous integration system, which must pass prior to a commit landing on the remote branch. Another example is when a project is managed by a set of committers that only accept pull requests (GitHub projects often do this). As a developer, I may want to create a feature branch, and then submit that branch for review (or submit a pull request to a repo committer). I then may want to continue local development while my teammates asynchronously review my code and the CI builds complete. To continue development on top of my previous commit, I may create a second local branch that tracks from my first local branch. This allows me to build from my first commit, even though that commit hasn't made its way to the upstream remote branch. Also, if someone suggests code review changes for my first branch, or the CI build fails, I can update that branch, and then rebase those changes into down-stream local branches. Here is how to set up a branch to track another local branch.
Given a local feature branch:
$ git co -b branch-1
$ git branch -u origin/master
Switched to a new branch 'branch-1'
$ git branch -vv
* branch-1 9f0c361 [origin/master] Some commit message
master 85ede1a [origin/master] Some commit message
This shows that local tracking branches master and branch-1 both track the master branch on the origin remote. I can now create another branch, and set it up to track local tracking branch branch-1.
$ git co -b branch-2
Switched to a new branch 'branch-2'
$ git branch -u branch-1 branch-2
Branch branch-2 set up to track local branch branch-1 by rebasing.
$ git branch -vv
branch-1 85ede1a [origin/master] Some commit message
* branch-2 85ede1a [branch-1] Some commit message
master 85ede1a [origin/master] Some commit message
One example I can think of is if you have a 'stable' branch. Then it would be nice if you could make a new branch, 'experiment' for example, and let it track the stable branch.
git checkout --track -b experiment stable
* do some experiments with some commits *
git push
Other than that it might be for consistency (that's just a guess).
The main things that come to mind for having a local branch track another local branch are (1) more informed messages from Git regarding a branch being ahead/behind of the tracked branch and (2) trigger hooks.
One area Git displays more information is when creating a branch. Creating a basic branch looks like the following:
While creating a tracking branch looks like:
This would add the following in
.git/config
:After committing some changes on branches
A
andB
, executinggit status -s -b
on branchA
displays## A
while on branchB
it displays## B...master [ahead 1, behind 1]
, providing some quick information regarding the relationship between branchesB
andmaster
.The other area where you might want a local branch track another local branch is to trigger hooks; in particular
pre-receive
,update
,post-receive
andpost-update
during agit push
. You might have hooks to, for example, trigger a build on a continuous integration server, do some license header checks, check for white space format errors, etc.Note that the ahead/behind information that you have between one branch '
B
' and another 'A
' tracked by the first only works if the branch.B.merge config is strictly defined:refs/heads/master
.It wouldn't work if it is loosely define: '
master
'.But with commit 05e7368, done by Junio C Hamano (
gitster
) for Git 2.3.0 (Q1 2015), this will work too.There are many occasions when tracking another local branch is useful. For example, in some git workflows, there something in place protecting master from directly receiving push requests. One example is a code review or continuous integration system, which must pass prior to a commit landing on the remote branch. Another example is when a project is managed by a set of committers that only accept pull requests (GitHub projects often do this). As a developer, I may want to create a feature branch, and then submit that branch for review (or submit a pull request to a repo committer). I then may want to continue local development while my teammates asynchronously review my code and the CI builds complete. To continue development on top of my previous commit, I may create a second local branch that tracks from my first local branch. This allows me to build from my first commit, even though that commit hasn't made its way to the upstream remote branch. Also, if someone suggests code review changes for my first branch, or the CI build fails, I can update that branch, and then rebase those changes into down-stream local branches. Here is how to set up a branch to track another local branch.
Given a local feature branch:
This shows that local tracking branches
master
andbranch-1
both track themaster
branch on theorigin
remote. I can now create another branch, and set it up to track local tracking branchbranch-1
.One example I can think of is if you have a 'stable' branch. Then it would be nice if you could make a new branch, 'experiment' for example, and let it track the stable branch.
Other than that it might be for consistency (that's just a guess).