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 Branch per feature (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...)
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?
TL;DR: What would be the best way to handle shared rerere and continue to use GitHub's Pull Requests, possibly still as the unit of integration/only required integration merge?
(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...)
It seems like my big hold up here is simply losing the "safety blanket" of the bright shiny "Merge Pull Request" button in GitHub. The team I am contemplating this workflow adjustment for has a wide mix of skill levels and right now the focus has been on UI-based workflows (GitHub, GitHub for Windows, and Visual Studio's Git-enabled Team Explorer), thus the interest in perhaps teaching GitHub new tricks rather than my fellow developers...
It looks like the key is simply to do more "offline" PR merges without that shiny green button. The key realization is that to keep the PR closures looking reasonably similar to what we have today (we try to enforce PRs as peer reviews), it becomes the added task of the code reviewer, when the PR cannot be auto-merged, to do the final integration merge. I'm worried that this could mean that PRs with integration issues quickly grow "stale" until a more senior developer has time to review and review well enough to do the merge, but this may also not be a bad thing in the long run.
The hub tool of course would help this workflow. It just adds to the burden of command line learning to train developers on.