Branching is a vital tool for all developers, working alone or in teams. The basic idea of feature branching is that when you start work on a feature, you create a branch off of the repository and commit all the changes for the feature onto the branch and when your feature is code complete then merge the changes back.
The advantage in using feature branches is that your main line (you might call main line ‘master’, ‘trunk’ or ‘head’ depending on the version control system you use) is kept clear of uncompleted features or bug fixes, which enables you to release software at any time because you don’t have to wait for all the features and bug fixes being worked on to be completed.
If concurrent development on other branches are in progress, it is a good idea to keep in synch with the latest changes on trunk. Synching with trunk helps avoiding the 'big' merge at code complete.
Test And Deployment Branches
The advantages mentioned above for feature branches, is also evident for test and deployment branches. We would like to isolate test and production versions from the continuous development made on trunk.
Every time a version is released to production it is versioned on its own branch. Should there occur any issues or hot fixes to any releases, these are made on the release branch and changes are merged back into trunk.
A test branch holds an isolated version that is currently being tested either by QA or business. Again, should there occur any smaller fixes, then these should be merged back into trunk. Larger changes, or feedback from business, should be put on a separate feature branch.
A good practice is to release to production from the test branch, so that the version that has been tested and verified by either QA or business, is the one being released to production. This means, that when we need to deploy to production, we merge trunk into the test branch and, when the revision is verified, we create and version a release branch from the test branch.Tweet
comments powered by Disqus