title: GitHub and "git bpf": PRs and git rerere
body: <p>Due to a combination of business needs and old habits, our QA/BA team members seem to think they need an ability to seemingly cherry-pick any combination of development work for a potential release candidate at release time. This worries me because at the moment this is leaving a lot of the git "scar tissue" in terms of revert and revert revert commits and "comment out" and "uncomment" commits which are sometimes worse. (Sadfaced aside: In darcs this would be a bit more easily attainable with the given tools, but of course we aren't using darcs we are using git.) In doing some research yesterday I came across the <a href="https://github.com/affinitybridge/git-bpf/wiki/Branch-per-feature-process" rel="nofollow">Branch per feature</a> (BPF) workflow automation efforts and their processes for maintaining "total isolation, total integration" (TITI). Now I'm trying to figure out if I can implement something similar in our work environment, hopefully without adding too much additional development process work and without throwing out the baby with the bath water to do so. (Not to mention the other questions of how I could potentially surface some automation to our QA/BA structure...)</p>
  
  <p>The TITI process in BPF relies heavily on a shared git rerere cache so that integration merges can be done in throwaway branches or in the integration branch, but be reusable for the cherry picking process when building release candidate (QA) branches. The particular point here is not to merge into the "source" branch to keep the source branch totally isolated. So I'm trying to figure out how that could work in a workflow where we are using GitHub PRs as the integration merge. Clearly a PR does not currently allow complicated merges and the current workflow is fix merge conflicts in the source branch, but that would violate the isolation principle if we were to try BPF. Theoretically we could do the throwaway merge technique, but how do you setup GitHub to share the rerere cache?</p>
  
  <p><strong>TL;DR:</strong> What would be the best way to handle shared rerere <em>and</em> continue to use GitHub's Pull Requests, possibly still as the unit of integration/only required integration merge?</p>
  
  <p>(Hacky Aside: Currently we only "need" to do this on one of our repositories and that repository is currently hosted on premises in GitHub for Enterprises, so there exists a small possibility that I could convince an admin with SSH access to hack the git config on the machine for that repository to turn on the shared rerere and auto-rerere. However there is a lot of frailty on relying on such a hack, including potential questions from other business units why they can't do what we are doing on public GitHub and also just the issues of potential GitHub updates breaking any git config hacks, presuming that they even work in the first place...)</p>