如何隔离受污染的合并主题分支上的提交,以便将它们应用于不同的分支?
Posted
技术标签:
【中文标题】如何隔离受污染的合并主题分支上的提交,以便将它们应用于不同的分支?【英文标题】: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 团队。它没有孤立的特性分支的纯度,但出于某种原因,它对我们来说工作得非常好。整合发生得较早,而且相对无痛。我们仍然在一个单独的分支中处理一个特性,但是每当主干更新时,我们都会将它重新定位到主干上。我们的历史也更加线性,这很好。
但最重要的是,我们不会再将主干合并到一个正在进行的分支中。太草率了,这是不允许的。重新定位到主干上,然后合并到其中。如果需要更多工作,请考虑为此启动一个新分支,以便您仍然可以私下变基(不要变基推送分支)。如果合并后分支严重失败,则恢复。在新分支上还原还原,修复问题,然后再次合并。
因此,对于最初的问题,认为可以通过从杂乱的分支中选择提交来提取特征是一种谬误;这个问题是错误的。
【讨论】:
以上是关于如何隔离受污染的合并主题分支上的提交,以便将它们应用于不同的分支?的主要内容,如果未能解决你的问题,请参考以下文章