Deconstructing a Branch with Git – Part 1 of 5

August 7, 2012 Jack Repenning

Everyone knows — it’s a basic Best Practice! — that you should do parallel development on parallel branches, not cascaded branches: base them both on trunk or master or whatever your favorite version control system calls it. Don’t branch one off the other, lest plans change, release schedules diverge, and you suddenly have to disentangle them.

Right? You knew that. I knew that. Everyone knows that.

You know where this is going.

<Insert favorite snarky gallows-humor quip>

The Problem — With Pictures

During development of our new CloudForge product, we also developed an API for our partners to use to integrate with us.

The Plan:

A simple cascading branch plan

What Really Happened:

A branch diagram that's out of control

Or something like that.

More branches were created than we’d expected. Intoxicated, perhaps, by Git’s vaunted branch magic, merges were done among branches that should never have been merged. Scope changed. Schedules changed. Priorities shifted. Brilliant new ideas appeared. The luster of old ideas sometimes faded.

You know: life happened.

Bottom line, the work I’ve been calling “branch 1” (CloudForge) increased significantly in scope, became far more wonderful in our eyes than it had ever before been … and was granted an Agile schedule extension to become all that it could be. Meanwhile, the work I’ve been calling “branch 2” (the API) remained prosaically un-replanned, basically on schedule, and steadfastly desirable in its own right and on its original schedule. When it came time to release branch2, there was no branch1 release vehicle to carry it.

Worse, much of the branch1 stuff had drifted over into branch2, and though we wanted to release branch2, we definitely did not want to release these bits of branch1—not yet, anyway. We were faced with the need to merge branch2 to master without the branch1 stuff, and to do it in a way that wouldn’t interfere, later, with delivering all this work as part of the branch1 release.

Around 1200 commits to assess, after discounting the around 600 merge commits.

In the end, after much trial and learning, we were able to use Git, Gitk, and cherry-picking to construct the branch would should have built in the first place. In my next few blogs, I’ll tell you how.

I know there are people out there with more experience in this—I’ve read all your blogs, believe me! Let us know how you’ve tackled these situations!

Follow the series by clicking below:


Part 2: Deconstructing a Git Branch — Tools Fail

Part 3: Deconstructing a Git Branch — The Tools…Seriously

Part 4: Deconstructing a Git Branch — A Guided Tour

Part 5: Deconstructing a Git Branch — Rolling Up Our Sleeves, Battling the Beast

Previous Article
Does ‘Who Makes a Good ScrumMaster’ Have Much To Do With Their Current/Past Role?
Does ‘Who Makes a Good ScrumMaster’ Have Much To Do With Their Current/Past Role?

Recently I’ve read a few blog posts and forum posts discussing, ‘what role do the best ScrumMasters come fr...

Next Article
Taming the Beast: How to Rank Large Backlogs
Taming the Beast: How to Rank Large Backlogs

When dealing with hundreds or thousands of stories, there is a quick way to simplify your backlog. You don'...