Feature Branches & Code Sharing

Mar 29, 2011 at 9:19 PM

Before I begin I wanted to thank you again for the branching strategy post you did a while back here. It is the basis for my branch refactoring proposal here and the basis for my question.

Some of the push back I have gotten on the strategy revolves around code sharing and feature branches. It mainly involves this scenario:

  • You have a major, long term feature a decent size team is working on - say a full db refactor or something that significant. Something that's going to take several months before its ready to integrate to Main.
  • You have another project that involves a decent sized feature change that is about 2 months out, not nearly as major as the first but still not ready to integrate to main.

Team 1 tells you that they need the changes from Team 2's branch because its enough of a major change to significantly affect what they are doing. They are willing to accept the fact that this code is not stabilized yet because it is such a major change they need to accommodate for it in what they are doing.

I'm assuming at this point we are looking at a baseless merge which wouldn't be ideal but I cant think of another way to handle something like this.

Mar 29, 2011 at 9:57 PM

You have two feature branches. Team 2 needs (wants) the code from Team 1.

I advise teams NOT to integrate code with other teams until it has been stabilized and the feature is either *ready to release* or *ready to share*. Of course we can't always stick to ideal best practice guidance.:)

You have a few options:

  • You could merge the code (RI)  from Feature Team 1 to Main and then merge from Main to Feature Team 2 (FI). This is the standard guidance. But you have already indicated the code is not ready to integrate with Main.
  • You could *anticipate* this situation and have an integration layer (branch) between Main and the Feature Team development branches. This is something we generally recommend against, since geting changes from a feature team branch to Main or from Main to a feature team branch requires twice as many merges in each direction. However, if you haven't already created the integation layer, than this is not an option either.
  • You could, as you suggest, do a baseless merge between the sibling branches (Feature Team 1 and Feature Team 2). We recommend, as a general rule, avoiding baseless merges because:
    • Files that are deleted in the source branch are not included in a baseless merge - they will not get deleted in the target branch.
    • More merge conflicts will result from not having a *common* baseline for the merge.
  • If you are using TFS 2010 SP1, you can now specify a starting range for a baseless merge. The specified changeset will now be used as the base in a three-way content merge. In addition, there is an improved approach for handling deletes. Starting with SP1, if a path is deleted in the source the corresponding path in the target will have a merge,delete conflict. Also, if a file is not deleted in the source but is deleted in the target, the target will get a merge,undelete conflict. You now have more control over how deletes are / are not propogated between source and target. These changes are possible as a result of changes to how items are identified in TFS 2010 in that merge lines up the items by path rather than by item ID.

Note that once you do a baseless merge between two sibling branches, future merges will now be *based* merges and can be done through the UI.

Bill Heys
VS ALM Ranger

Mar 31, 2011 at 3:48 PM

OK, we are in the process of upgrading to SP1 so I'm assuming that #4 would be our choice given an unfortunate situation of a unplanned need to merge sibling branch changes.


Question on this process, would you suggest the baseless merge contain a limited number of changesets and then immediately perform a second, standard merge for the rest of the changes or bring all of the needed changes in via the baseless merge?

Mar 31, 2011 at 3:57 PM

I have been thinking a little about recommending doing a baseless merge between sibling branches, right after creating the second (sibling) branch.

I am not sure what the difference (user experience) would be if you do a baseless merge with a minimum of changes followed by a standard merge, vs doing a more extensive baseless merge.

I might try to experiment with various options and then blog :)

Bill Heys
VS ALM Ranger