Simple branching advice

A friend of mine asked me the following questions:

  • Are you working in different branches?
  • Are you working in the same project as other developers at the same time?

As this is a topic of much debate at most offices around the world, I’m writing my own advice here. As I work almost exclusively in Visual Studio, my experience and advice is limited to that environment, and to relatively¬†small teams.

Here’s my rule:

Try to avoid branching at all times!

Branching always costs valuable time. It takes time merging. It takes time resolving conflicts or a bad merge. It takes time explaining how it works and what features should be implemented on what branches. It takes time keeping track of your branches.

Here’s the workflow I prefer, which avoids almost all conflicts:

  1. Write a little piece of functionality.
  2. If it works and builds, check it in.
  3. If you know your affecting other developers, be sure to communicate this to them. Then check it in.
  4. Make sure your team gets the latest source after you added a conflicting change (I’m looking at you code first migrations!).

I almost never encounter any problems using this workflow. It’s great. Even when working with more developers in one project, you shouldn’t encounter much trouble.

That said, there are 2 scenario’s when I do use branching:

  1. Feature Reviews
    When there’s a new or junior developer, I always let them work on their own branch first to implement a feature. When they are done, they create a pull request in VSTS so we can review their work together. We can discuss the code and make changes if required.
  2. Production Releases
    Once you’ve got a version in production, you have to be able to provide hotfixes for it. I do this by creating a branch for that release. When there is a critical bug, it can be fixed on that branch. If applicable the fix can be merged back into the main branch. Creating a branch for each release you need to support and developing further on the main branch keeps the merges as limited as possible.