好的,情况如下:我的两位同事研究了两个新功能(feature_1
和feature_2
)。现在一个分支feature_1
发生了一些变化,另一个开发人员希望在他的分支feature_2
中看到。所以他将分支feature_1
合并到他的分支feature_2
中。它可以这样说明:
合并前:
P--o--o--o master
\\
\\B--C--D feature_1
\
\A--E feature_2
合并后:
P--o--o--o master
\\
\\B--C--D feature_1
\ \
\A--E---M feature_2
他推动了合并提交,两位开发人员都将继续在他们的分支机构工作。
P--o--o--o--o--o--o master
\\
\\B--C--D--o--o--o feature_1
\ \
\A--E---M---o--o feature_2
现在是时候将feature_2
合并回主人了。但是如果我们这样做,那么从feature_1
(至少从feature_1
到feature_2
的最后一次合并中的所有更改)将合并回主节点。但由于feature_1
还没有准备好,这不应该发生。
那么我们怎样才能" unmerge"来自feature_1
的{{1}},因此feature_1的提交不会合并为主。
我尝试在feature_2
上执行git rebase master
,但这只会删除合并提交M,但保留提交B,C和D(或者更多预设B',C&# 39;和D {#39;)feature_2
。
有关如何从feature_2
feature_1
提交提交的任何想法?我们不介意重新定义并强制推送或仅使用feature_2
的提交创建新分支。
更新(我的解决方案):
感谢@kan,他为我的合并问题提供了一个很好的解决方案。在评论中,我们还讨论了当从feature_2
到feature_1
的多次合并发生时如何解决它。我已经在单个命令中找到了一个解决方案。我们假设有以下情况:
feature_2
所以我们合并了两次。没有必须做两次rebase。第一个是P--o--o--o--o--o--o--o master
\\
\\B--C--D--o--o--o--o feature_1
\ \ \
\A--E---M--o--M2--o feature_2
,第二个是--onto M2^ M2
。这可以通过以下单个命令完成:
--onto M^ M
这将基本上从git rev-list --ancestry-path master..HEAD --merges | xargs -I % git rebase --onto %^ % feature_2
到master
HEAD
范围内的所有合并提交,并从右到左"在"上运行rebase。因此它将首先在rebase中使用M2而不是M.如果只有一个合并提交,也可以使用此命令,但只能使用较短的feature_2
命令。
答案 0 :(得分:2)
最明显的方法 - 执行rebase -i
并手动删除feature_1的提交。如果有太多提交要手动过滤,请告诉我,我会更加努力思考......
确定。更加努力......;)
我建议,只有一个合并点M.在这种情况下,你应该在合并点之前将合并提交之后的所有提交重新绑定到提交。使用git rebase --onto E M feature_2
。
答案 1 :(得分:2)
由于此特定合并已被推送,您将需要revert the merge commit。
git revert -m 1 <SHA-of-M>
如果您想再次从feature_1
重新引入任何更改,则必须还原还原,但这是最安全的选项,因为它会保留您提交的历史记录
澄清一点&#34;还原恢复&#34;:假设您已将此分支合并为主分支。
P--o--o--o--o--o--o---F2 master
\\ /
\\B--C--D--o--o--o / feature_1
\ \ /
\A--E---M---o--R/ feature_2
如果要将feature_1
合并到master
,则必须先将合并后的恢复提交还原为master(因此,您必须还原{ {1}}提交)。
R