To Branch Or Not To Branch

Well this is really an interesting topic that came into my mind after I went off from our internal meeting regarding the project development strategies. Branching is a feature that has really been misused more often, which often leads to the question: To Branch Or Not To Branch?

Well the answer is pretty simple, you should not branch! With branching comes merging into the picture and really, the complexity of branching increases the pain of merging exponentially. For common scenarios simply labeling the build solves the problem however with parallel isloated development activities in place, branching is the only answer.

After googling the seed on the web I found more strength to it and here’s the plant finally grown up in shape of my blog entry 🙂

Here are some common scenarios which gives an insight as to when and how you should branch:

  • Scenario 1 – your team works only from the main source tree. In this case, you aren’t creating branches and you don’t need isolation. This scenario is generally for smaller or medium sized teams that don’t require isolation for teams or for features, and doesn’t need the isolation for releases.
  • Scenario 2 – your team creates branches for release. In this case, your team creates a branch to stabilize the release and then merges the release branch back into the main source tree after the software is released.
  • Scenario 3 – your team creates a branch to maintain an old build. In this case, you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. You may or may not merge the maintenance branch back into the main tree. For example, you may work on a quick fix for a subset of customers that you either don’t want to add to the main build or you don’t want to add at this time.
  • Scenario 4 – your team creates branches by features and teams. In this case, you create a development branch, you perform work in the development branch, and then you merge back into your main source tree. The branch may be organized by features or by teams.
  • Scenario 5 – your team creates branches for features and teams, as well as for releases. You create a branch for parallel development. You can organize by features or teams. You branch from your main branch into your development branch and you perform integration builds into your main tree. You create a branch for your production releases and then merge these back into your main tree.

Key Notes

  • Scenario 1 is generally a smaller team that doesn’t have to worry about isolation.
  • Scenario 2 is the next most common case where you need to create a branch to stabilize for a release.
  • Scenario 3 is a common case for teams who need to perform maintenance on released builds.
  • Scenario 4 is generally used by larger teams who have dedicated feature teams or discrete development teams working in isolation.
  • Scenario 5 is generally used by larger teams who not only have development teams working in isolation but also need to create a branch to stabilize for a release.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s