Quick Tips on Branching Patterns from an Expert

The goals of a branching pattern should always to be to manage a software team’s development process and to make this process as easy and straight-forward as possible. With this process, the team should be able to complete all of the things that need to happen in order to release a piece of software. So how you establish this pattern?

Make Merging Changes Easy and Straight-forward

Whiteboard Quick Tips on Branching Patterns from an ExpertThe funny thing about branching patterns is that we often attempt to create a process, but have a hard time following it. Typically someone from the team will draw the branching pattern on the whiteboard, and even go as far to take a picture of it with a phone to send around to teams.

Unfortunately this process doesn’t scale well when development teams have more than a few people. Change management on the whiteboard isn’t an effective system for ensuring the success of a software release.

Branching patterns should be able to support the development process, and mirror the natural flow of the development team as they work towards a release.

To achieve this, we might want to think of branches as a process management tool, not just a place to put a specific release, patch or development build.  Promotional branching patterns allow for different “states” of code, which is hugely powerful when working through the development cycle. This is a huge topic that is part of larger conversation. To find out more about promotional branching and merging patterns check “A Guide to Branching and Merging Patterns.”

Provide Private Areas for Teams to Check-in and Integrate

Committing early and often is an SCM best practice. Over the years, developers have been told “If it’s not in source control, it never happened.” To avoid this philosophy, teams may require people to check code in everyday so work isn’t lost.

In a practical branching pattern, teams and developers create both private workspaces and branches, allowing them to create builds, releases, and tests of code before they push those changes to other team members. Avoid using mainline type branching patterns that don’t provide code stages; this leads to broken code and unfinished work making its way into a release.

GDD Quick Tips on Branching Patterns from an ExpertManage Distributed Teams

Collaborating and sharing code with distributed teams is more complex than ever – teams routinely develop in one location and test or perform other tasks in another location. This distribution of teams strains the development process, yielding security, auditing, and integration problems.

Development teams must appear to be co-located while utilizing the same process with lower complexity. This means code integrations with other projects should happen in real time, so teams can give each other feedback immediately. The branching pattern and process must be followed by everyone, to ensure they are all on the same page.

Understand What has been Delivered

User Stories, bugs, and requirements drive any process, but the ability to see what changes match such items and the location of those code changes are often overlooked in the branching structure.

There is a magical feature that many SCM tools have, called “change-sets” or “Change Packages” in AccuRev. Change Packages associate your changes in the branch with an issue, so you can stay organized and move issues from branch to branch, without having to remember what file went with what issues.

Take these pieces of advice, and they will help if you want to build a release with “finished” issues or if you want traceability into what people are currently working on for a specific release.



Posted in: AccuRev, Best Practices, change packages, SCM, Tips and Tricks

Leave a Comment (1) ↓

1 Comment

  1. Richard Winks February 14, 2012

    Managing the merge is our biggest concern. It has been my experience that developers dread it and consequently avoid it. We have project groups that insist that all checkouts are locked so that they can check things back in without conflict.

    “Merging your code changes with someone else’s when there is a conflict slows down my development”, is a common complaint. In our case the number of developers is small and it isn’t as if they can’t work it out, it’s just that some see this as an impediment.

    Branches in our organization tend to be very thin. All development is performed on the mainline (at the tip) builds are performed and tested from the mainline. Come time for release lockdown, one project group branches for release. The other group simply marks the branch with a label and moves on. If additional code changes are required a branch is created from the label. There is no intermingling between product groups so separate processing does not seem to cause concern to anyone other than myself who has to deal with both.

    In our case the branch process is more influenced by the developers’ culture and acceptable practices than anything else.

Leave a Comment

Anti-Spam Protection by WP-SpamFree