Do you know when to branch in TFS (aka TFVC)?
Last updated by Brady Stroud [SSW] 7 months ago.See historyOne of the most controversial issues developers discuss is when to create branches and how many you should have.
Keep things simple:
- Have the team develop on the one branch. It is fantastic as there is no more merging hell.
- Have that branch called "main" (or " trunk " when using TFS or SVN
Note: This rule only applies to TFVC. For git, see Do you know when to branch in git?
Beware of smart bloggers giving the wrong advice 🙃 as many smart people like creating branches... E.g. Guidance: A Branching strategy for Scrum Teams. Even Martin Fowler says there are a number of issues related to merging that lead us to try and minimise the number of branches that we work with in his article on Feature Branches.
The quintessential scenario you need to support is that emergency "Hey we have a security hole on the site and Hanselman has just tweeted it!"
In that case you need to potentially update all of your branches and perform deployment, which can be quite tiresome.
The better way is to use OctopusDeploy which relieves developers from having multiple branches because you only have to worry about building on one branch and deployment can be done automatically to multiple environments. Octopus provides more secure, feature-rich environment which makes it very easy to deploy and promote builds between environments.
Why you should avoid branching
- Merging is painful, complex and is a time consuming task that does not add value
- Often regressions are introduced as merges are missed and not merged back to trunk
- The longer branches are, the more people that have worked on them... the more unpleasant the merge is going to be Amount of pain = size of the change * the amount of work on the trunk in that period
- The more you need to create a branch, the harder it is going to be to merge it back into the trunk!
- Branching impedes refactoring
If a am working on a branch and perform sweeping renaming, and a developer working on another branch does the same – merging is nearly impossible.
This is very likely to happen on code bases that require tidying when you have developers who believe in improving code as they go (see the Boy Scout rule)
When it's OK to branch
- For a disposable, investigatory spike
- To perform hotfixes to production environment
