In this post I describe my pattern of Git usage.

My project (NuGet support for TeamCity) contains two main branches called 'v0.5-bugfix' and 'v0.6-bugfix'. 'v0.5-bugfix' branch is targeted for TeamCity 6.5.x. 'v0.6-bugfix' is targeted for TeamCity 7.0 and contains more features.

To start a new feature development I first decide if I want this feature to be delivered for 0.5 or 0.6 version. Let's suppose I decided to create a feature for both versions. I create a branch 'task' for it from 0.5-bugfix by calling:

 git checkout -b task v0.5-bugfix

As work is done I merge branch 'task' onto 0.5-bugfix via:

 git checkout
      v0.5-bugfix
 git merge task

Main work is done. New feature is implemented in branch 'v0.5-bugfix'. Now it's time to merge it onto v0.6-bugfix. For it I create a branch 'task6' from v0.6-bugfix. Than I merge branch 'task' into 'task6'.

      git checkout -b task6 v0.6-bugfix
 git merge task
 git checkout v0.6-bugfix
 git
      merge task6

And in the rest I remove obsolete branches by:

 git branch -d task task6

That was it. The feature is ready for both branches. It's time to push.

Another trick I found useful is to try to create branch from the lowest possible version even if you do not need it. In future that will let you simply merge the feature to older version.

To update from remote repository I use the following:

 git fetch origin
 git merge origin/branch

This way of updates let's you avoid issues if remote branch has new commits and your local branch has another commits. I do not like rebase because it requires force push (-f) with possible history overwrite if you decide to push it once more after rebase.

All recent fixed to NuGet plugin for TeamCity I did using this practice. Current public version of the plugin contains all fixes and features that are applicable to the version. It was easy to take two branches in sync. This is a VCS commits graph I saw today:

You may find the source of the graph on GitHub

comments powered by Disqus