由于业务需求和旧习惯的结合，我们的 QA/BA 团队成员似乎认为他们需要能够在发布时为潜在的发布候选者挑选任何开发工作组合。这让我很担心，因为目前这会留下很多 git 的“疤痕组织”，以还原和还原还原提交以及“注释掉”和“取消注释”提交，这些提交有时会更糟。（除了悲伤：在 darcs 中，使用给定的工具会更容易实现，但当然我们没有使用 darcs，我们使用的是 git。）昨天在做一些研究时，我遇到了每个功能的分支(BPF) 工作流自动化工作及其维护“完全隔离、完全集成”(TITI) 的过程。现在我正试图弄清楚我是否可以在我们的工作环境中实现类似的东西，希望不会增加太多额外的开发过程工作，也不会把婴儿和洗澡水一起扔掉。（更不用说我如何在我们的 QA/BA 结构中显示一些自动化的其他问题......）
BPF 中的 TITI 过程严重依赖于共享的 git rerere 缓存，因此可以在一次性分支或集成分支中完成集成合并，但在构建候选发布 (QA) 分支时可重用于樱桃采摘过程。这里的特别之处是不要合并到“源”分支以保持源分支完全隔离。因此，我试图弄清楚这在我们使用 GitHub PR 作为集成合并的工作流程中是如何工作的。显然 PR 目前不允许复杂的合并，并且当前的工作流程是修复源分支中的合并冲突，但是如果我们尝试 BPF，那将违反隔离原则。理论上我们可以使用一次性合并技术，但是如何设置 GitHub 来共享 rerere 缓存？
TL;DR：处理共享 rerere并继续使用 GitHub 的拉取请求的最佳方式是什么，可能仍作为集成单元/仅需要集成合并？
（Hacky Aside：目前我们只“需要”在我们的一个存储库上执行此操作，并且该存储库当前托管在 GitHub for Enterprises 的本地，因此我可以说服具有 SSH 访问权限的管理员破解 git在机器上配置该存储库以打开共享 rerere 和 auto-rerere. 但是，依赖这样的 hack 有很多弱点，包括来自其他业务部门的潜在问题，为什么他们不能做我们正在做的事情公共 GitHub 以及潜在的 GitHub 更新问题，这些问题破坏了任何 git config hacks，假设它们甚至可以在第一时间工作......）