Version Control Features
Version Control is the management of changes (versions) to documents, files, and software.
Trunk/Head/also called the first branch – is the main body of source code. Branches begin as a copy of the first or subsequent branches – and are for adding new features or experimentation without affecting the branch they stem from. Eventually they are merged to the original branch and cease to be of use. Merging is integrating the changes of a branch – normally back to the original branch. Tagging/labelling – is a marker on a branch so we can retrieve the source code as it existed at that point in time.
If we are not careful we can create a bigger problem than the solution version control was intended for.
Strategies for Version Control
1. Simple Strategy
First Branch is used for development, and the support branch is used to support the production version
- New software developed on the first branch and when ready for release we tag the first branch to mark it. We make a copy of the first branch named “Support Branch” in this example. New development can continue on the first branch. The release is made to the customer from the first branch.
- A customer detects a problem and it is fixed on the support branch – not containing on-going development that is on the first branch. The release is made to the customer from the support branch this time. The support branch is tagged to mark the point of the release – so we can rollback if need be.
- When we release from the first branch again we want to include the fix from the support branch – so we copy/merge that change to the first branch
- Now when we make a release from the first branch it will include all changes made on the support branch.
2. Release Branch Strategy
Release Branch Strategy slightly extends the simple strategy – First branch is for development, the release branch supports the test environment rather than the production environment as in the simple strategy.
Some organizations require parallel testing and want fixes in the test environment to be more immediate.
Release Branch Strategy supports on-going development, and both test and production environments that have different versions of the software.
- New software developed on the first branch and when ready for release we tag the first branch to mark it. We make a copy of the first branch named “Release Branch” in this example. New development can continue on the first branch. The release is made to the test team from the first branch.
- A tester detects a problem and it is fixed on the release branch – not containing on-going development that is on the first branch. The release is made to the test team, from the release branch this time. The release branch is tagged to mark the point of the release – so we can rollback if need be. It is possible that a fix is identified in the first branch in which case it can be fixed in either first or release branch and then merged to the other.
- When we release from the first branch again, we want to include the fix from the release branch – so we copy/merge that change to the first branch
- Now when we make a release from the first branch to the test team it will include all changes made on the support branch.
When release branch is deemed ready for release to the customer, we release from the release branch and tag it at the point of release.
3. Feature Branch Strategy
The feature branch strategy has no upper limit on the number of branches – there is one branch for each feature. It separates teams and features onto their own branch. When the feature branch is finished it is merged into the first branch and the feature branch deleted.
- First branch is only for accepting merges from feature branches, it is not developed on. In this example feature branches A, B, and C are all created from the first branch at different times in that order.
- In this example feature branch B is first to complete and is merged to the first branch and tagged. During this merge it does not have to contend with changes made on feature branch A
- Now feature branch A is completed and merged to the first branch. Not only does it have to deal with conflicts between the first branch and feature branch A but it also has to deal with conflicts caused by the merge of feature branch B. Feature branch C has yet to be merged.
Best Practice
- Use the rules of the version control software you have implemented – and choose wisely which one you use.
- Keep branches to the minimum
- Use change evaluation and feature switches to remove the requirements for branches, and predict when a merge can be difficult and plan around it
- Only use the Feature Branch Strategy when there are large numbers of high-risk changes – or if the feature adds new objects with little modification to existing objects. Use Release Branch Strategy for other development – better still use change evaluation and feature switches to avoid a feature branch
- Merge regularly. The greater the change and the longer the time results in the greater differences between branches – and even if it is still possible to merge .
