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?
2
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).
3
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.
2