如何隔离受污染的合并主题分支上的提交，以便将它们应用于不同的分支？

Posted 2023-03-06

【中文标题】如何隔离受污染的合并主题分支上的提交，以便将它们应用于不同的分支？

【英文标题】：How to isolate commits on a contaminated, merged topic branch, in order to apply them to a different branch?

【发布时间】：2016-02-02 15:33:40

【问题描述】：

更新 tl;dr：不要让自己陷入这种情况，这是可以避免的。

如何隔离在下面的功能分支上提交的 f 提交？目标是将它们应用到 release-candidate 分支，而不从 master 或 wip-feature 引入任何东西。

在大多数情况下，从 master 到 feature 分支的合并不是功能运行所必需的。我们想在 release-candidate 分支上证明是这样的。

/-F0----F1--\-F2 wip-feature（未准备好发布） / \ m0------**--------m1--m2--m3--m4--m5--m6--m7--m8 主控 \ / \ / \ / \ / \-f0-/ \-f1-/ 功能（可能准备发布，但不干净） \ / \-r0-----r1--r2--r3 release-candidate（每个“合并”都是一个独立的功能，或者是从生产中向后合并的修补程序） \ / \-p0-/ 生产（接收来自候选发布和修补程序的批发合并）

不幸的是，从 m6 合并到功能分支，这确实使事情变得复杂，但人们似乎总是会找到这样做的理由（保持与其他正在进行的工作的兼容性，合并对开发环境的改进等.)

到目前为止，我一直在做一个git log --oneline --graph --decorate --all，并目视检查这棵树，以便进行一次大的樱桃采摘操作。我挑选到基于目标分支的中间分支，以便我可以通过合并来应用它；与樱桃选择不同，该合并是我可以恢复的。这样做的问题是，当特性分支上有大量提交，并行处理大量特性分支，并且时间跨度相对较长时，很难跟踪那个分支的线程。

我会检查功能分支并以交互方式将其变基到 release-candidate，在此过程中删除 m5 和 m6，但是当我尝试这样做时，m2 和 m3 被包含在变基操作中, 这是一个简化;实际上，我不得不放弃大约 50 个提交。这可以工作，但它也非常手动且容易出错。

我正在寻找的最终结果，从 release-candidate 分支来看，将是这样的：

--r2--r3--f0--f1 释放候选

如果在候选发布时通过了 QA，那么我会将整个内容合并到生产环境中并标记发布。如果没有，那么我将恢复引入 f* 提交的合并，这样我们仍然可以选择将发布候选合并到生产环境中。

我需要找到一种方法来隔离 f* 提交，而不会遗漏任何内容或从其他分支中提取任何提交。

【参考方案1】：

事实证明，这真的只是一个糟糕的主意。开发人员可能会认为他们的功能完全驻留在单个分支提交上，但如果该分支被来自另一个分支的合并污染，那么从那时起程序员正在针对新环境进行编码，无论他们是否意识到这一点。

对于我们来说，我们过去曾尝试过gitflow 工作流的几种变体，但在合并时遇到了集成问题。我们还想单独对每个功能分支进行功能和系统测试，但考虑到在我们的主要项目。

现在我们正在做一些类似于基于中继的部署，包括功能切换和专门的 QA 团队。它没有孤立的特性分支的纯度，但出于某种原因，它对我们来说工作得非常好。整合发生得较早，而且相对无痛。我们仍然在一个单独的分支中处理一个特性，但是每当主干更新时，我们都会将它重新定位到主干上。我们的历史也更加线性，这很好。

但最重要的是，我们不会再将主干合并到一个正在进行的分支中。太草率了，这是不允许的。重新定位到主干上，然后合并到其中。如果需要更多工作，请考虑为此启动一个新分支，以便您仍然可以私下变基（不要变基推送分支）。如果合并后分支严重失败，则恢复。在新分支上还原还原，修复问题，然后再次合并。

因此，对于最初的问题，认为可以通过从杂乱的分支中选择提交来提取特征是一种谬误；这个问题是错误的。