合并分支的交互式变基

Question

我正在使用git，目前进入了以下状态：

      X --- Y --------- M1 -------- M2 (my-feature)
     /                 /           /
    /                 /           /
   a --- b --- c --- d --- e --- f (stable)

当我们在'my-feature'分支上工作超过一天时，就会出现这种情况。 M1和M2是从稳定分支合并到功能分支中的。M1和M2可能存在合并冲突，已经解决了这些冲突。 将稳定分支合并到功能分支的整个想法是尽早处理冲突。

一旦功能完成，我们希望将功能分支变基为一个或两个提交。

问题是当我们进行交互式变基时，Git会显示与我们已经解决的M1和M2合并期间相同的合并冲突。

有没有办法让Git重用我们在M1和M2中已经做出的合并决策？

- Ido Ran

---

可能是git合并后的git变基的重复问题。 - Ciro Santilli OurBigBook.com

Answer 1

如果合并冲突是相同的，则这是git中最有用（虽然较不为人知）的命令之一git rerere的完美使用案例。来自man页面的介绍：在采用相对长寿的主题分支的工作流程中，开发人员有时需要多次解决相同的冲突，直到主题分支完成（无论是合并到“发布”分支还是发送并被上游接受）。该命令通过记录手动合并的冲突自动合并结果和相应的手动解决结果来协助开发人员进行此过程，并将先前记录的手动解决方案应用于其相应的自动合并结果。git rerere会记录您的冲突解决方案，并在git merge、git rebase或提交合并时（提交合并时）自动应用它们。Scott Chacon发布了一些很好的例子(点击此处)，而man页面也值得一读。

你可以通过输入以下命令在merge和rebase中启用git rerere:

git config --global rerere.enabled true

如果您只想为单个存储库启用该选项，请删除--global标志。

- Christopher

---

谢谢。我已经了解过rerere，但直到现在才开始使用它。 - Ido Ran

我有一个关于这个的问题：我们在团队中工作，当其他人正在处理合并冲突时，rr-cache目录将存在于他们的机器上。它会被复制到主存储库吗？还是我可以在团队之间共享rr-cache数据？ - Ido Ran

rr-cache不通过远程共享，但如果您通过其他方式共享实际的rr-cache目录，则应该可以工作。这里有一个关于将rr-cache本身作为符号链接存储库的好答案：https://dev59.com/ClXTa4cB1Zd3GeqP2YRP#5410923。 - Christopher

Answer 2

git rebase --interactive --preserve-merges

- forvaidya

---

我已经尝试过preserve-merges，但我的错误似乎是我标记了合并提交以进行压缩。现在我又重新做了一遍，并只标记了M2之后的提交以进行压缩。 - Ido Ran

小心使用rebase的这种标志组合，它可能会产生出人意料的结果：http://article.gmane.org/gmane.comp.version-control.git/148059 - Christopher

是的，我已经了解到同时使用 -i 和 -p 可能会有危险。我从不重新排序提交，只选择要挑选和合并哪些提交。我注意到如果我在合并之后立即压缩提交，则可以迫使 git 重新创建合并提交并“直接”提交历史记录线。 - Ido Ran

有没有一种方法可以在保留合并的同时编辑旧的提交？ - lkraav

我认为这并没有解决原帖作者的问题，因为没有任何解释，所以我也不能确定。 - hmijail

Answer 3

将功能分支feature显式地转换为一个新的分支feature-one-commit，并只有一个提交记录：

git checkout -b feature-one-commit \
"$(git commit-tree HEAD^{tree} -m "Commit message" -p master)"    

- Ciro Santilli OurBigBook.com

---

这对我来说是最简单的解决方案，它也让我意识到了git-commit-tree。_Git_确实是一个深不可测的兔子洞，呵呵。 - Ainar-G

Answer 4

你可以始终使用 -f 标志来强制执行它

- chrisbulmer