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 GitHubcomments powered by Disqus