Branch yourself from fear – Branch and Merge

code without fear
Developing can get to your head. We have ideas on how to avoid mindgames, get beyond fear, and keep your sanity.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

When it comes to centralized source control systems such as Microsoft Team Foundation Server and Subversion, why are people so scared of the words “branch” and “merge”?  I’ve been working on medium to large software teams for nearly a decade and in that time I’ve seen nearly the same response every time I bring up code branching to solve a problem – UNBRIDALED FEAR.  It usually goes like this:

Product Dev – “We need to get started working on and   as soon as possible, but I’m worried about people blocking each other due to build breaks and regressions, what do you think we should do?”

Me – “Well, lets create some feature branches so that each crew can consume the other’s work when they are ready and we know it’s stable.”

Product Dev – “Yikes, I didn’t realize we’d have to branch to solve this.  That’s too hard and will take too much time. Let’s just take the build-break and regression-risk hit and move forward. We’ll watch it closely and re-evaluate if it becomes an issue.”

Me – “But branching takes like 5 minutes and by the time we re-evaluate it’ll be too late.”

Product Dev – “Yeah but then we have to explain it to people and they’ll have to deal with really complicated code merging. The team won’t like it.”

Me – “But if the feature code touched in each branch doesn’t really overlap, the code merge will be automatic. Also, they can mitigate complicated merges by just doing them more frequently so they consume smaller chunks of work, which is probably a better idea anyway.  It encourages people to check in frequently and test in real time.”

Product Dev – “I just don’t feel comfortable asking the team to do this right now. Maybe we can try in the next release.”

Usually this is followed by a development cycle that ends up being full of problems just like Product Dev was worried about. As a by-product the team is more stressed out than they need to be, team morale is lower, people work longer hours to fix problems that could have been avoided and play catch up due to lost time.

After seeing this time and time again, I’ve come to the conclusion that development teams’ fear of branching creates a self-fulfilling prophecy of complexity and hassle.

So what should you do?

sharepoint ideasIf the story above resonates with you then you can one of two ways…

Option 1 – Stay centralized and use Process to make the team cultural shift

In this case you simply need to use branching when it makes sense! This is harder than it sounds, but it’s possible. Branching needs be part of the team culture and if it’s not already, making the shift will probably require a few things:

  • Sponsorship from team leaders and above – if the development leaders don’t “walk the walk” then why should the team?
  • Incorporation into the team’s normal process – you do code reviews right? I thought so.  Make branching and merging part of your CR process.
  • Education, education, education – brown bags, whitepapers and practical on-the-job training will help people ramp up and get over their wariness.

Option 2 – Get crazy and go to distributed version control!

Distributed Version Control Systems (DVCS) are the future (and honestly, tons of developers would argue that they are the ‘now’). People using a DVCS such as Git can branch, edit, & commit files locally and then push and pull them in batches to a remote server. This alleviates the need for server side branching in many cases by allowing feature teams to manage merging code in a peer-to-peer fashion.

classification in sharepointHow do you move to DVCS once you’ve made the call? Well, if you have TFS or Subversion, you can use a “bridging” tool to turn your centralized VCS into the remote repository for a DVCS. All of these bridges use Git as a local repository on the developer’s machine and then “bridge” to the remote repository of TFS or Subversion. Here’s some links to common bridges

  • Git-TF – An open-source multi-platform Git to TFS bridge written in Java by Microsoft. Use Git and TFS together on your Mac!
  • git-tfs – Also an open-source Git to TFS bridge, but written in C#, depends on the TFS client object model and currently only for Windows clients.
  • git-svn – A linux-based add-on for git, so usage in Windows is done via Cygwin. Check out this blog entry for a quick rundown on getting started.

Regardless of your DVCS bridge selection you’ll have to educate team members on the tool usage so in the end you’ll need to educate people on proper branching no matter what. The choice to move to DVCS just pushes the ownership further into the individual team members’ hands, encouraging them to learn it faster and leverage it more often for better productivity.

Nick Nieslanik – VP Engineering

More To Explore

remote worker
Digital Workplace

How to Work Remotely

Working remotely is hard for some people. We have ideas to make it easier.

We can help

teams and teamwork