Lean Development Principles for Branching and Merging


the repository. For example, in tools such as Subversion, Perforce or Team Foundation Server, branches exist in the path space of the repository - make sure their location and the naming standard used is regular enough to be automatable.

Task Branches - Help or Hindrance?
Task branches are aimed at allowing changes to be made independently from a mainline and merged back as one complete unit. They permit frequent check-ins which may contain value, yet which are perhaps not fully tested and thus risk breaking the mainline.

There are many organizations, particularly agile development shops, which do not like to use Task Branches at all due to the perceived overhead of merging changes, and the dangers of delaying changes. They prefer to make all changes on the mainline and to deal with conflicts within the workspace.

As we mentioned in our original Branching article [1], there is in fact no difference between resolving a conflict which results from a Private Workspace Update, and the conflict which results from merging between two branches. In the same article we suggested the possibility of branching on conflict (the equivalent of the Private Checkpoint pattern) to ensure that the original workspace version is saved in the repository. This was specifically to address the requirements of an agile project.

Automated Merging Between Branches
This may seem rather dangerous to many people, and yet it is well worth considering.

To be able to do it at all will require good development practices and tools:

    • Reliable automatic merge tool
    • Developers checking in consistent change sets
    • Automated builds and unit tests to provide suitable quality guarantees

Of course it is not possible to automate 100% of merges, and there will always be the need for developers to get involved to resolve conflicts or failed tests.

The more you keep your change sets small and consistent, and merge each one individually, not in one big lump, the more likely it is that automated merge will be of benefit. In addition, the cleaner the code under development, the easier life will be too!

In the worst case scenario a subtle bug might be introduced. Some organizations are so fearful of this that they ban it outright, but bugs happen often enough with ordinary developer changes anyway, so the overall increase in productivity or automated merging (inspite of occasional introduced issues) is likely to be significant (consider appropriate metrics to track this).

Chris Berarducci describes the use of automated particularly in maintaining localized versions of a product . While the original article was written in 2003, it is still in use within Palm and of major benefit.


Critical to the "Merge as you go" success are:

    • The SCM Tool's merge facilities
    • Established roles and responsibilities
    • A single automated daemon
    • Conflicts can be handled on the engineers CPU

Development engineers like it:

    • They own the configuration and merging; they do not need to consult with another group or person to turn on or off the auto merge daemon.
    • They are relieved from thinking about merges unless there is a conflict or configuration change needed. When it is on and configured, changes checked into one tree will be migrated to the destination tree(s) in a timely and reliable manner.
    • It's easy to set up and the configuration files are tracked in the SCM tool.
    • It's easy to turn off and on

More information is provided in the submission comments:

  • Easier for QA and Program Management to generate release notes, and for other non-technical users to understand changes and their history

While the system as defined works very well, Palm are looking at managing

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!