CODEWITHSUNDEEP
tfs
David Palau
David Palau

Reputation: 3

TFS Branching Strategy Advice Needed for Specific Changes

Looking for some branching strategies for a situation that has come up for a development effort of ours. We are using TFS 2010 and are using a basic two branch branching scenario with three branches: Dev, Main (which is the stable, primary branch that the other two were branched from), and Release. Currently Main and Release are the same and a lot of changes are going on in the Dev branch.

When we started the latest development project, it was assumed that we would follow our normal practices and take everything that was done in the Dev branch up to a point and then start the release process. Well, as usual, things change and now we are looking to only take some of the work that was done in the Dev branch (~20% of the changes) and want to do a release off that.

Most of the changes we are looking to promote are stand-alone but there are a few files that would need to be gone over and keep only the release functionality we care about.

So, given our current two-branch strategy, how do we reconcile something that should have been initially structured more along the lines of a multiple feature based branching strategy?

This is our first big project with TFS and unfortunately we weren’t practicing good source management by having Changesets include things for multiple features, not using Labels, etc.

The worst case scenario in my mind would to make a new branch off of Main, call it Feature1, and then have to manually copy over the changes to the Feature1 branch from the Dev branch. Is this the only way or is there something more efficient?

Upvotes: 0

Views: 244

Answers (1)

Malin E
Malin E

Reputation: 16

Yes, I think you need to create a new branch. But I would not call it Feature1. I would start to use the Release branches.

Create a Release branch from Main. Then you merge (no manually copying) everything you plan to include in the release from Dev. If the Main branch has no changes, the merges should not result in any conflicts. Now you can start the stabilization work in the Release branch.

Work can continue in Dev and when the release is ready, you merge all fixes from Release to Dev and all changes to Main.

Due to that you do not use labels today I think you should lock the Release branch. For the next release you create a new Release branch. (Make sure to think of a good naming convention for all release branches before you start) Then you are always able to go back to every release.

Upvotes: 0

Related Questions