Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a branching structure of:

  • multiple dev branches for each major new feature
  • Main branch, merged into from a dev branch once a feature is ready for testing
  • Release branch, merged into from Main once a feature is ready for production

We often have new features completed at around the same time that end up in Main, with some of the same source code changed. Then Feature A may be declared ready for production and need to be deployed, while Feature B requires more work.

Once changes are incorporated in Main, particularly with multiple revisions to Feature A and B, their identity as separate features is lost. It then becomes risky and difficult to promote just one of them to production. We use TFS and I don't know if this is one of its limitations.

What is the best way to resolve this? Should we be using a different branching strategy, or would a DVCS fix it?

share|improve this question
What VCS are you using? – Daniel Kaplan Jan 17 '13 at 5:57
@Daniel TFS - it's in the question, maybe not clear enough – Alex Angas Jan 17 '13 at 7:26

Don't merge to main (or trunk) for testing. Trunk should always "ready-to-go" code, meaning it may not have all functionality, but will not be broken code.

Think of trunk as code you can release at any time.

Test your branches, and when they pass, merge to trunk, immediately do an integration test and then tag and deploy when ready. If the new code fails the integration, then revert, merge changes from trunk into branch and then fix the problem. Once the branch works, rinse and repeat.

You will not lose your history because you can always traverse backwards through the logs (assuming you're using something sane; CVS/VSS are not sane).

share|improve this answer
Testing should take place on the feature branch surely. Reverting should be a last resort. – James Jan 17 '13 at 2:56
As mentioned on James' answer, how do we test several dev branches at the same time? – Alex Angas Jan 17 '13 at 3:26
Then how do you test that the integration with the main branch succeeds? In other words, that it does not interact with other recently merged branches? – Andre Jan 17 '13 at 8:37

You need to have someone who pushes changes from Main to each sub-branch regularly. Do the testing on the dev branches individually. Once one feature has been approved for release its changes must be merged into the other feature branches via Main. Then push to Release.

Releasing should be done on a FCFS basis unless there are dependencies.

Having different features modify the same code may result in your merge tool failing and a headache for some poor soul.

share|improve this answer
I would like us to do testing on the dev branches, but we would then need to test several dev branches at the same time which still integrates all the "WIP" code together. – Alex Angas Jan 17 '13 at 3:25
@AlexAngas Then the problem is that your dev branches are too tightly coupled. The work needs to be divided out better. If it cannot then everyone should work from the same feature branch – James Jan 17 '13 at 15:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.