Deconstructing a Branch with Git – Part 1 of 5

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

Tagged with: , , , , , ,
Posted in CloudForge, Git

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

connect with CollabNet
   Contact Us
Subscribe

Have new blog posts sent directly to your email.

looking for something
conversations

CloudForge: Join #CollabNet for the TeamForge® 8.1 release webinar and learn about its new powerful enterprise #Git features http://t.co/IHfnkoEfGr
Date: 1 September 2015 | 5:00 pm

CloudForge: Join this #CollabNet #webinar and learn how to reduce server loads with #Git replication and improve Git performance http://t.co/pB1DEsWFPh
Date: 31 August 2015 | 6:00 pm

CloudForge: Seamlessly integrate #Git upstream and downstream to tools such as #Jira and #Jenkins on this #CollabNet #webinar http://t.co/pB1DEsWFPh
Date: 28 August 2015 | 5:30 pm