0

I'm looking for the correct branching and merging strategy for the situation I'm currently in. A few weeks ago I created a new Dev branch from Main for version 1.6 of an application. This version is now being tested and will go live in the coming weeks.

Starting today I need to begin development for version 1.7, but I'm unsure how to proceed in TFS. I think there are 2 scenario's:

1. The dev branch for 1.7 is created from Main (as usual), and I integrate all 1.6 changes into the 1.7 branch and start my development. Any changes in the 1.6 will be merged into the 1.7 branch as soon as they are ready to be tested.
2. The dev branch for 1.7 is created by branching the 1.6 dev branch, any future changes in 1.6 will again be merged as per point 1.

The problem with #1 is the fact there is no direct relation between 1.6 and 1.7 according to TFS, which results in baseless merges.
The problem with #2 is the fact there is no direct relation between 1.7 and Main, which results in a baseless merge later on, when 1.7 is completed and merged with Main.

Is this a situation where baseless merges can't be avoided, or is my entire strategy wrong?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
MeanGreen
  • 3,098
  • 5
  • 37
  • 63

1 Answers1

1

I'm assuming Main represents your last stable release and may be open to receiving hotfixes and the like to resolve critical issues. I'm also assuming that the typical workflow is that you begin developing a "vNext" version -- in this case, 1.6, and then work on that branch until you've completed work on it, then merge it into Main. The problem is that you're using ever-shifting development branches for your next release. You don't want to branch off of 1.6 to 1.7, because then you'd have to merge from 1.7 to 1.6 eventually, and then that 1.6 branch no longer accurately reflects what version 1.6 was.

I'd simplify things a bit. Create two "permanent" branches:

  • Main - your current stable "production" version
  • Dev - your in-development version (1.6, in this case)

Developers can work against Dev normally. When it's "done-done" and becomes the current stable version, it's merged to Main.

Now you have the ability to make feature branches (for longer-running, isolated features that aren't necessarily going out in the next release) or "vNext" branches (for stuff slated for the next release that you've discovered you have capacity to start working on earlier than anticipated).

Now you can create a branch off of Dev for your 1.7 work, and reverse-integrate your 1.6 changes into 1.7. When 1.7 becomes the new development target, merge 1.7 into Dev, and delete the 1.7 branch.

If you want to maintain older versions, you can use labels on the Main branch to represent each stable version, or you can create release branches to represent them.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • Thank you for the feedback. I think you're suggesting a decent solution. For this release I'll use the 1.6 dev branch as long as 1.7 is in development, and use it as your suggested 'permanent ' Dev branch. I've created the 1.7 from the 1.6 branch and will use it as an intermediate to prevent having baseless merges. – MeanGreen Jul 20 '17 at 14:43