0

We have two branches; Development (whereby developers regularly check/integrate into) and Main (where code from Development is merged into for versioning/releasing).

When reading about branching "strategies"/"best practices", it is said that Development must be a branch of Main. Development must be branched from Main.

For example, when reading about Development Isolation in the VS ALM Ranger's Branching Strategies document, it says how "the development branch should be a full child branch of the main branch".

Why can't Main be a full branch from Development? From how I understand, Development will almost always contain everything (excluding hotfixes) that Main has.

Merging from Development to Main is the more common scenario. Does it even matter in this case which is the "original" and which is the branch?

Note: We are using Visual Studio Team Services

Esther Fan - MSFT
  • 8,276
  • 4
  • 27
  • 25
Dave New
  • 38,496
  • 59
  • 215
  • 394

1 Answers1

1

In all of my experiences with using TFS we use the following schema:

-Main Branch (This branch will reflect the current deployed code)

--Staging Branch (This branch will act as a testing environment for QA. This can be removed if it doesn't make sense in your case.)

---Development Branch (This is the branch that the developers will be checking into regularly.)

Our reasoning behind this setup is that the main branch will reflect the current deployed code on the server. This way if we do need to do a hot fix it can be completely isolated from the current development cycle so nothing we are working on will sneak into the fix.

The staging branch will be essentially where your QA department will perform its validation. Some organizations handle this differently so this might not apply to your situation.

The development branch will be the most "experimental" branch. This has the highest potential for having bugs and general developer shenanigans. We place this branch around the bottom because if a developer finds him/herself needing to create a branch off the development branch for any reason the flow of information will make sense. Merge up to push changes, and merge down to get the updated changes.

I stumbled upon this post that has a much better explanation on the best merge practices. This should answer any confusion I introduced (:

TFS: Merge best practices

Community
  • 1
  • 1
Kevin
  • 26
  • 3
  • Thanks for your answer. My questions is more about WHY Development needs to be branched off from Main and not the other way around? How does this make a difference from a merging perspective? – Dave New Oct 19 '15 at 15:50
  • 1
    I think you'll get a better idea if you review the link on best merge practices but let's say you want to add another branch from your current parent branch (**development**). By adding the branch (**Staging** for example) you will now have **Development** as the parent of both **main** and your **staging** branches. This creates an issue if you want to merge to **staging** for testing, then merge the **staging** branch to the **main** branch for deployment while continuing your development cycle. The direction (or Flow) of changes is what we need to look at here. – Kevin Oct 19 '15 at 16:07