git - 合并分支的交互式变基

Question

我正在使用 git，我正在进入这个状态：

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

当我们在“my-feature”分支上工作超过一天时，就会发生这种情况。M1 和 M2 从稳定分支合并到特征分支。M1 和 M2 可能已合并冲突，但已解决。将 stable 分支合并到 feature 分支的整个想法是尽早处理冲突。

一旦功能完成，我们希望将功能分支重新设置为一两次提交。

问题是当我们进行交互式 rebase 时，git 向我们展示了我们在 M1 和 M2 合并期间已经解决的相同合并冲突。

有没有办法让 git 重用我们在 M1 和 M2 中已经完成的合并决策？

Answer 1

如果合并冲突相同，这是git rereregit 中最有用（尽管鲜为人知）命令之一的完美用例。从手册页：

在使用相对较长生命周期的主题分支的工作流中，开发人员有时需要一遍又一遍地解决相同的冲突，直到主题分支完成（合并到“发布”分支，或者发送出去并接受上游）。

此命令通过在初始手动合并上记录冲突的自动合并结果和相应的手动解决结果并将先前记录的手动解决方案应用于其相应的自动合并结果来协助开发人员完成此过程。

git rerere记录您的冲突解决方案，并在 、 或 （提交合并时）遇到相同的冲突时自动git merge应用git rebase它们git commit。Scott Chacon在这里发布了一些很好的示例，手册页也值得一读。

您可以通过发出以下命令git rerere来启用：mergerebase

git config --global rerere.enabled true

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

Answer 2

git rebase --interactive --preserve-merges

Answer 3

通过一次提交将功能分支feature变为新分支的显式方法feature-one-commit：

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

Answer 4

您总是可以使用 -f 标志强制它