I am on a software project which has about 10 developers, we share source code via Mercurial. We have a development and production branch per release. Repeatedly during the course of the project we have had source code from one branch i.e. v1 getting into patch and maintenance branches for earlier releases of software i.e. v2.
This results in either time spent backing out the wrong commit, or wrong (possibly non-QAd) code reaching and getting deployed in the wrong branch if we don't notice that the code has gone into the wrong branch.
Our branch and merge design/method
v1-test v1-patch1 v1-patch2 ^---------^-----------^ v1-prod / / \ \ -----------------------/ \ \ v1-dev \ \ \ --------------------------\ v2-dev \ \ \ ^-------^------------- v2-prod v2-test v2-patch1
Hence we will work on a release development branch, until it's deemed ready, branch it off for a single testing/UAT/Production branch, where all releases and maintenance is done. Tags are used to build releases of this branch. While v1 is being tested, a branch will have been made for v2 and developers will start working on new features.
What tends to happen is that a developer commits work due for v2-dev branch into v1-dev or v1-prod, or worse, they merge v2-dev into v1-prod (or similar such mistakes).
We tell most developers not to access the -prod branches, however code still sneaks in. A group of more senior developers `look after' the -prod branch.
It should be noted that while v2 has just started development, there may still be some quite hefty patches going into v1 to fix issues. I.e. v1 may not just be getting the odd small patch.
What we've tried so far
- Having a separate -prod branch, with gatekeepers. A -prod branch should raise warnings through its name and most developers don't need to ever be in that branch. This has not really reduced the problem.
- Raised awareness of this problem amongst the developers, to try and make them more vigilant. Again this has not been very successful.
Possible reasons I see for developers committing to the wrong branch
- Too complex a branch design
- Having active development in multiple branches in parallel. (The project does exhibit symptoms of using the avalanche-model.)
- Developers don't understand the DVCS well enough
Questions I've read which were somewhat relevant
I've read this question on not committing to the wrong branch and I feel that the answers regarding visual cues may be helpful. However I am not entirely convinced that the problems we're experiencing are not symptoms of a more fundamental problem.
With the visual clues, we can incorporate them into the command line easily, however about half the team use eclipse which I'm unsure how to incorporate visual cues.
What methods, in the form of software, project management or governance can we use to reduce (ideally stop) commits to the wrong branch taking up our time or dirtying our deployed code?
Specific comment on the reasons I believe may be contributing as outlined above would be appreciated, but this shouldn't limit your reply.