如何隔离受污染的合并主题分支上的提交，以便将它们应用到不同的分支？
How to isolate commits on a contaminated, merged topic branch, in order to apply them to a different branch?
更新 tl;dr：不要让自己陷入这种情况，这是可以避免的。
如何隔离在下面的功能分支上提交的 f 提交？目标是将它们应用到候选发布分支，而不从 master 或 wip-feature 引入任何东西。
在大多数情况下，功能运行不需要从主分支到功能分支的合并。我们想在候选发布分支上证明情况确实如此。
/-F0----F1--\-F2 wip-feature (not ready to release)
/ \
m0------**-------m1--m2--m3--m4--m5--m6--m7--m8 master
\ / \ / \ /
\ / \-f0-/ \-f1-/ feature (probably ready to release, but not clean)
\ /
\-r0-----r1--r2--r3 release-candidate (each "merge" is an isolated feature, or a hotfix merging backwards from production)
\ /
\-p0-/ production (receives wholesale merges from release-candidate, and hotfixes)
从 m6 合并到功能分支是不幸的，这确实使事情变得复杂，但人们似乎总是找到理由做这样的事情（保持与其他正在进行的工作的兼容性，合并对开发环境等）
到目前为止，我一直在做 git log --oneline --graph --decorate --all，并目视检查树以组合一个大的 cherrypick 操作。我挑选到一个基于目标分支的中间分支，这样我就可以通过合并来应用它；与 cherry-pick 不同，该合并是我可以恢复的。这样做的问题是，当特性分支上有大量提交时，大量特性分支并行工作，并且时间跨度相对较长，很难跟上那个分支的线程。
我会检查功能分支并以交互方式将其变基到候选发布版本，在此过程中删除 m5 和 m6，但是当我尝试这样做时，m2 和 m3被包含在rebase操作中，这是一个简化；实际上我不得不放弃大约 50 个提交。这可以工作，但它也非常手动并且容易出错。
我正在寻找的最终结果，从候选发布分支来看，将是这样的：
--r2--r3--f0--f1 release-candidate
如果通过候选版本的 QA，那么我会将整个事情合并到生产环境并标记一个版本。如果没有，那么我将恢复引入 f* 提交的合并，这样我们仍然可以选择将候选发布版本合并到生产环境中。
我需要找到一种方法来隔离 f* 提交，而不会遗漏任何内容或从其他分支中获取任何提交。
事实证明，这真的只是一个糟糕的想法。开发人员可能认为他们的功能完全依赖于单个分支提交，但如果该分支被另一个分支的合并所污染，那么从那时起，程序员就会针对新环境进行编码，无论他们是否意识到这一点。
对于我们来说，我们过去曾尝试过 gitflow 工作流程的几种变体，并且 运行 在合并时遇到集成问题。我们还想单独对每个功能分支进行功能和系统测试，但发现设置功能分支测试环境并不是我们（我）可以通过合理的努力自动化的事情，考虑到大量的集成服务我们的主要项目。
现在我们正在做一些类似于基于 t运行k 的部署，具有功能切换和专门的 QA 团队。它没有独立功能分支的纯粹性，但出于某种原因，它对我们来说工作得非常好。整合发生得早，而且相对轻松。我们仍然在一个单独的分支中处理一个特性，但是每当 t运行k 更新时，我们都会将它重新定位到 t运行k 上。我们的历史也更线性，这很好。
但最重要的是，我们不会再将 t运行k 合并到正在进行的分支中。那只是马虎，这是不允许的。变基到 t运行k，然后合并进去。如果需要更多工作，请考虑为此启动一个新分支，这样您仍然可以私下变基（不要变基推送的分支）。如果分支在合并后严重失败，则恢复。在一个新的分支上恢复revert，修复问题，然后再次合并。
所以，对于原题，认为可以通过从杂乱的分支中挑选提交来提取特征的想法是谬论；题错了
更新 tl;dr：不要让自己陷入这种情况，这是可以避免的。
如何隔离在下面的功能分支上提交的 f 提交？目标是将它们应用到候选发布分支，而不从 master 或 wip-feature 引入任何东西。
在大多数情况下，功能运行不需要从主分支到功能分支的合并。我们想在候选发布分支上证明情况确实如此。
/-F0----F1--\-F2 wip-feature (not ready to release)
/ \
m0------**-------m1--m2--m3--m4--m5--m6--m7--m8 master
\ / \ / \ /
\ / \-f0-/ \-f1-/ feature (probably ready to release, but not clean)
\ /
\-r0-----r1--r2--r3 release-candidate (each "merge" is an isolated feature, or a hotfix merging backwards from production)
\ /
\-p0-/ production (receives wholesale merges from release-candidate, and hotfixes)
从 m6 合并到功能分支是不幸的，这确实使事情变得复杂，但人们似乎总是找到理由做这样的事情（保持与其他正在进行的工作的兼容性，合并对开发环境等）
到目前为止，我一直在做 git log --oneline --graph --decorate --all，并目视检查树以组合一个大的 cherrypick 操作。我挑选到一个基于目标分支的中间分支，这样我就可以通过合并来应用它；与 cherry-pick 不同，该合并是我可以恢复的。这样做的问题是，当特性分支上有大量提交时，大量特性分支并行工作，并且时间跨度相对较长，很难跟上那个分支的线程。
我会检查功能分支并以交互方式将其变基到候选发布版本，在此过程中删除 m5 和 m6，但是当我尝试这样做时，m2 和 m3被包含在rebase操作中，这是一个简化；实际上我不得不放弃大约 50 个提交。这可以工作，但它也非常手动并且容易出错。
我正在寻找的最终结果，从候选发布分支来看，将是这样的：
--r2--r3--f0--f1 release-candidate
如果通过候选版本的 QA，那么我会将整个事情合并到生产环境并标记一个版本。如果没有，那么我将恢复引入 f* 提交的合并，这样我们仍然可以选择将候选发布版本合并到生产环境中。
我需要找到一种方法来隔离 f* 提交，而不会遗漏任何内容或从其他分支中获取任何提交。
事实证明，这真的只是一个糟糕的想法。开发人员可能认为他们的功能完全依赖于单个分支提交，但如果该分支被另一个分支的合并所污染，那么从那时起，程序员就会针对新环境进行编码，无论他们是否意识到这一点。
对于我们来说，我们过去曾尝试过 gitflow 工作流程的几种变体，并且 运行 在合并时遇到集成问题。我们还想单独对每个功能分支进行功能和系统测试，但发现设置功能分支测试环境并不是我们（我）可以通过合理的努力自动化的事情，考虑到大量的集成服务我们的主要项目。
现在我们正在做一些类似于基于 t运行k 的部署，具有功能切换和专门的 QA 团队。它没有独立功能分支的纯粹性，但出于某种原因，它对我们来说工作得非常好。整合发生得早，而且相对轻松。我们仍然在一个单独的分支中处理一个特性，但是每当 t运行k 更新时，我们都会将它重新定位到 t运行k 上。我们的历史也更线性，这很好。
但最重要的是，我们不会再将 t运行k 合并到正在进行的分支中。那只是马虎，这是不允许的。变基到 t运行k，然后合并进去。如果需要更多工作，请考虑为此启动一个新分支，这样您仍然可以私下变基（不要变基推送的分支）。如果分支在合并后严重失败，则恢复。在一个新的分支上恢复revert，修复问题，然后再次合并。
所以，对于原题，认为可以通过从杂乱的分支中挑选提交来提取特征的想法是谬论；题错了