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")
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
- 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& andofficial-vendor-releasessuch that we can continue to rebase only with commits made since the most recent vendor release.
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.
Is this not a great opportunity to use the Open-Closed Principle?