In the contributor workflow, it mentions that you should create your topic branches tracking origin/master (a remote branch):

git checkout -b New_Branch_Name origin/master

It might be easy to forget the "origin/master" part. And now you've started doing work on the branch but you're anxious and would like to make sure you did it correctly. Here's how.

The "git branch" command (without any arguments) will list the branches in your repository. For example:

#> git branch
IUD_costing
* license_update_4
master

This tells you that you have three branches in your repository, IUD_costing, license_update_4 and master. If you add the -v parameter you get more info:

#> git branch -v
IUD_costing 8dffe98 [TRAFODION-28] Part 3 of changes to update license text
* license_update_4 8dffe98 [TRAFODION-28] Part 3 of changes to update license text
master e50b3f8 [behind 3] Merge remote branch 'origin/pr/35/head' into mrg_22

This tells you what the last commit was on your branch. But still not good enough. If you add the -vv parameter, you get even more info:

#> git branch -vv
IUD_costing 8dffe98 [origin/master] [TRAFODION-28] Part 3 of changes to update license text
* license_update_4 8dffe98 [origin/master] [TRAFODION-28] Part 3 of changes to update license text
master e50b3f8 [origin/master: behind 3] Merge remote branch 'origin/pr/35/head' into mrg_22

Here, right after the SHA value, you see the branch that each branch is tracking. You also see how up-to-date it is. In this example, all of the branches are created tracking origin/master. The first two are up-to-date, so a push from these branches is less likely to have a merge conflict. (Though you should do a git fetch --all before pushing to get the latest remote information.) The master branch in this example is three commits behind. So the good news in this example is that all the branches indeed were created as recommended, tracking origin/master.

 

  • No labels