Question

我有一个包含两个分支的存储库，main 和 feature。 git log --graph --format='%s %d' --all 的输出如下所示：

* e  (main)
| * d  (HEAD -> feature)
| *   Merge branch 'main' into feature 
| |\  
| |/  
|/|   
* | c 
| * b 
|/  
* a

我现在想将 e 分支上的提交 main 包含在 feature 分支上的合并提交中，以便我拥有 main 上的最新更改，但如果 b 分支上的提交 feature 已经被推送，则不必强制推送。我也不想在我的历史记录中再有一次合并提交。我希望我的最终图表如下所示：

| * d  (HEAD -> feature)
| *   Merge branch 'main' into feature 
| |\  
| |/  
|/|   
* | e  (main)
* | c 
| * b 
|/  
* a

我可以通过 git rebase -i main --onto :/a --rebase-merges 实现这一点，并将交互式 rebase 的说明更改为：

label onto

reset 9870d06 # a
pick 579c27a b
merge -C d4caa73 main # Merge branch 'main' into feature
pick f672b7f d

问题在于，在之前的合并提交中，我必须解决 b 和 c 之间的冲突，而使用这种方法，我将不得不再次解决此冲突。因此，我真正想做的是在 c 上的提交 main 处停止的合并提交，然后继续将 e 合并到 feature 的顶部b。有没有办法实现这一目标？也许还有一种方法可以暂时引入另一个合并提交，然后再压缩这两个合并提交？

Answer 1

Git 确实包括为这种工作流程设计的东西。有一个问题：您必须在进行第一次合并之前打开它。

幸运的是，有一个名为 git rerere-train 的第三方解决方案可以解决这个问题，它现在包含在 Git 发行版中（但仍未直接安装）。参见，例如，对 Smarter rebase avoiding redundant work?

接受的答案

虽然这个问题（从八年前开始！）是关于变基的，但同样的概念也适用于 git merge 执行的 --rebase-merges。实际上，rebase 期间发生的冲突是合并冲突。您不需要脚本可以完成的完整培训；您可以使用 this method（来自十年年前！）来教 Git 您之前使用的分辨率。

请注意，一旦您打开 rerere.enabled，Git 将继续检查以前的分辨率并重新使用它们，即使您不希望这种情况发生（例如，如果您意识到您错误地解决了某些问题并想重新做一遍）。不过，您可以使用与打开它时相同的 git config 操作来关闭它。另请注意，即使打开了 re-use recored resolutions (rerere) 选项，Git 也会在发生冲突的合并后停止采取这些记录的决议。这让您有机会检查结果。

更新先前的合并提交而不解决冲突两次

1 个答案: