Best Practices For Branching with teams


Source Control

Branch for Team. You branch to isolate sub-teams so they can work without being subject to breaking changes, or can work in parallel towards unique milestones.

Development is branched from Main and used to isolate active development. Development branches may be temporary, in order to develop risky changes without impacting Main.

Main contains your main source tree. Changes from other branches are integrated here.

Releases contains branches you have already shipped but now need to maintain for customers. This provides isolation from the active development occurring in your development branch. It also contains a current release branch which is branched from Main and contains the version you are currently locking down prior to release. You work in this branch to prepare your software for release, while others continue to work in the Development branch working on new features.

Branch for Team

There might be a one-to-one correspondence between team and feature, but in some cases a team might work on multiple features. 

The following is a physical view showing branching for sub-team development:

My Team Project

└ Development → Isolated development branch container

│     └ Team 1 → Team branch

│     │     └ Feature A → Isolated branch for development

│     │     │         └ Source

│     │     └ Feature B → Isolated branch for development

│     │                └ Source

│     │

│     └ Team 2 → Team branch

│            └ Feature A → Isolated branch for development

│            │          └ Source

│            └ Feature B → Isolated branch for development

│                    └ Source

└ Main → Main Integration branch

        └ Source

Rationalize your branch/merge strategy with the frequency with which you want to produce builds. A deeper branching structure results in more time to merge from child branches to the main integration branch. 

Symptoms of this causing a problem for your development team include:

Broken builds where the fix takes too long to propagate up to the main integration branch.

Missed milestones because features take too long to propagate up to the main branch.

Large amounts of time are spent merging changes between various branches.

If this becomes a problem for your team, consider reducing the depth of your branching structure.

The following is an example of a complex branching structure:

My Team Project

└ Development – Container to isolate active development branches

│     └ Feature A – Isolated branch for development

│     │     └ Source

│     └ Feature B – Isolated branch for development

│             └ Source

└ Main – Main integration and build branch. All changes come together here.

│     └ Source

│     └ Other Asset Folders

└ Releases – Container for current release and maintenance branches

│     └ Release 2– Active maintenance branch

│     │      └ Source

│     │      └ Other Asset Folders

│     └ Release 3 – Active maintenance branch

│     │      └ Source

│     │      └ Other Asset Folders

│     └ Release 4 – Branch containing the code currently being locked down to release

│             └ Source

│             └ Other Asset Folders

└ Safe Keeping

       └ Release 1 – Old release in safe keeping

└ Source

               └ Other Asset Folders

This structure includes:

Feature branches for multiple teams to work in isolation.

A main branch to gather changes by all teams as well as bug fixes from the release branches.

A release branch used to lockdown the current release.

A maintenance branch for an old release that is being actively maintained and supported.

Safekeeping branches for older releases that are no longer being maintained.

Do not branch unless your development team needs to work on the same set of files concurrently. If you are unsure about this, you can label a build and create a branch from that build at a later point. Merging branches can be time consuming and complex, especially if there are significant changes between them.

Do not branch too deeply. Because it takes time to execute each merge and resolve conflicts, a deep branching structure can mean that changes in a child branch may take a very long time to propagate to the main branch. This can negatively impact project schedules and increase the time to fix bugs.

Summary

Branches are usually created to lock down a release, to maintain a previous release, or to support isolated parallel development. You should not branch unless you have good reason to do so.

When creating branches, you should logically structure your branch trees so that you only need to merge along the hierarchy (up and down the branch tree) rather than across the hierarchy. Merging across the hierarchy is time-consuming and error-prone.

For large teams, the branching structure is deeper, so you should be prepared for more lag time between a change occurring in a development branch and that change being merged back into the main integration branch.

http://msdn.microsoft.com/en-us/library/bb668955.aspx

clip_image001

About johnnblade aka johnnyblade Thugnology

C# Developer 9Ja Thugnology
This entry was posted in Source Control and tagged , , , , , , . Bookmark the permalink.

1 Response to Best Practices For Branching with teams

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s