Recently I’ve come across some problems on managing trunk/branches/tags. As a result of manual merging two branches I’ve ended up with hours spent on editing conflicts and checking the system. It’s obvious this was not a good sign as new bugs might have been introduced.
I’ve decided to organise the way the revision control system is used. Below you can find descriptions of two most common scenarios.
All team members work only on current release
As you see in the picture above the whole team works only on current release (nobody implements features for upcoming releases).
- When system testing cycle starts a new tag is created so that there’s a snapshot of the current state of the application.
- If bugs are found fixes are implemented and checked in to (main) development branch/trunk.
- When new system test cycle starts a new tag is created.
- The whole process is repeated until there’s no bug found or the state of the application is satisfactory.
Part of the team works on bug fixing and others implement features for next release
This is a more complicated scenario when part of the team is responsible for fixing bugs found in the system test cycles whereas the rest works on implementation of features that should be released after the current one.
- When first system test cycle starts a new tag is created so that there’s a snapshot of the current state of the application.
- Work on next release can be performed. Code is checked in to the main dev branch/trunk.
- If there were no bugs found (good joke…) that’s it – you can stop reading here.
- In real life some bugs will be found though; they must be fixed. A new branch should be created from just created tag and any bug fixes should be committed to that branch. This way two parts of the development team don’t interfere each others’ work
- Whenever a new system test cycle starts a new tag is created from the branch used for bug fixing and that’s repeated until there’s no bug found or the state of the application is satisfactory.
- Bug fixes need to finally be included also in main dev branch. This can be done by merging dev branch with branch used for bug fixing in two ways: (i) when final version of current release is ready (one big merge at the end); (ii) when bug fix is committed to the branch (several small merges). You need to choose which option is better for you – sometimes one big merge is enough, but you can end up with loads of files that need merging and possible conflicts might arise.
Final remark – not a single check in should be made to a tag.
Please bear in mind these are my thoughts, which can be not perfect. If you use a different approach and you believe it’s better, don’t hesitate to share it with me (us).
Maybe anyone can recommend some articles/books on how to administrate IT pojects with regards to revision control system?
