git-for-proprietary-vendor-customization.markdown

Maintaining ease of upgrades when customizing proprietary software

This repository is for a project charged with customizing some proprietary vendor's (relatively non-volatile) codebase, but also providing a safe and straightforward way of surviving and integrating future vendor-provided patches and point-releases. A graph describing the approach:

      B-C-D-E------------o---H-I-J-----------o ("develop")
     /                  /|                  / \    
    /      F+B'+C'+D'+E' |         o+H'+I'+J'  \ (local rebase branches)
   /       |             |         |            \ 
  /        |             o---------o-------------o  ("vendor-develop-integration")                
 /         |                      /
A----------F---------------------K ("official-vendor-releases")

Legend

A   a commit
o   a merge commit
A'  the commit A applied as part of a rebase operation
/   merge onto above branch
\   merge onto lower branch
|   branch creation
+   rebase application of a commit       

Branches

• develop is the public branch on which all changes to the vendor-provided code are applied (developers also actively integrate topical/feature branches here)
• official-vendor-releases is committed to with each vendor-provided patch or point-release.
• vendor-develop-integration represents a common line of ancestry between develop & and official-vendor-releases such that we can continue to rebase only with commits made since the most recent vendor release.

Discussion

The aspect that makes this situation unusual is that the time interval from official release A and F might span months of active work on develop, and performing a single merge from commit F onto develop might be too broad and complex to be safe.

The idea is to use rebase to apply each of the (presumably many, many) develop commits to the latest official release. Then, to preserve the history in develop, we'd merge vendor-develop-integration onto develop.

So vendor-integration is a "staging" environment? If so, it could receive commits continually from your dev work, not just all at once.

Why not split up "development" into an assortment of branches - one for each feature? Then you can more easily revert a single feature if it doesn't meet the standards for a release.

Hey Marc:

1. I'm currently evolving this a bit, vendor-integration will be changing a bit. I'll update the gist as soon as I can
2. I also presume we'll have topic and feature branches throughout; for the sake of keeping the discussion simple, I'm just excluding them from view here since they'll be integrating into the develop branch anyway.

Okay, I've updated things somewhat to make it more clear what vendor-develop-integration is for, and how the rebases would be performed in temporary local branches. Make any more sense?

As this graph gets bigger, I may need to buy you all a beverage over which to talk this.

Is this not a great opportunity to use the Open-Closed Principle?