为什么我使用 git rebase 时会再次出现相同的冲突？

Question

我已经阅读了关于 SO 上 git merge 和 git rebase 的相关问题，但我仍然无法完全理解幕后发生的事情。

这是我们的分支情况：

MASTER------------------------
        \        \
         \        \----Feature B---
          \                        \
           \-----Feature A----------\---Feature A+B

给定 2 个在不同时间源自 master 的特征分支，我们现在想要合并这 2 个分支。我们想遵循first rebase then merge 的做法，但是当我们将功能 A 重新定位到功能 B 时，我们会遇到冲突。这是意料之中的，因为两个特性（和主特性）在相同区域都有变化。但奇怪的是，同样的冲突在git rebase --continue之后不断重现。这让我们发疯，所以我们最终中止了 rebase，并使用git merge。事实证明，这些冲突其实很容易解决。

我的问题有两个：

1. git rebase 适合我们的情况吗？还是 rebase 仅适用于引入一些（例如 1 或 2 个）更改？
2. 幕后发生了什么导致相同的冲突一次又一次地出现？我的理解是rebase 一次解决一个冲突，但它比较的是哪个提交，它与什么比较？

关于 SO 的相关帖子：

• Why do I have to resolve the same conflict over and over?
• https://stackoverflow.com/questions/7241678/how-to-prevent-lot-of-git-conflicts-when-git-rebasing-lot-of-commits\
• git rebase resolve conflicts again and again?

Answer 1

rebase 适合你的情况吗？

基于Feature A 和Feature B 似乎是共享 分支这一事实，我会说不。

变基是一种合并分支的方法无需合并提交（即具有两个或更多父级的提交），使其显示为线性历史。最好用于合并本地分支，即仅存在于本地存储库中且尚未发布给其他人的分支。为什么？至少有两个原因：

1. 变基会更改提交 ID（即其元数据的 SHA-1 哈希）。这意味着，一旦您将重新定位的提交推送到共享分支，它们将显示为完全新提交，任何在其本地存储库中获取它们的人，即使它们仍然包含同样的变化。现在，如果有人同时在旧提交之上添加了新提交，他们将不得不移动它们。这会造成不必要的混乱。

2. 当您合并公共分支时，您经常希望拥有这些合并提交，以便能够跟踪提交如何跨分支移动。这些信息会因变基而丢失。

幕后发生了什么？

只是一个常规的合并。不同之处在于git rebase 将一次提交合并到前一个提交之上，从公共父级开始。 git merge 将两个提交（连同它们的整个更改集）合并为一个操作，因此您只需解决一次冲突。

更新：解决反复出现的冲突

正如@Jubobs 在 cmets 中指出的那样，Git 确实有一个自动解决方案来解决多次发生的冲突：git rerere，或“重用记录的解决方案”。

在你的配置文件（rerere.enabled true）中启用rerere后，每次发生合并冲突时，Git都会记录冲突文件的状态之前和之后你合并它们。下次发生同样的冲突时——涉及合并两侧的完全相同的行的冲突——Git 将自动应用它之前记录的相同分辨率。它还会在合并输出中让你知道它：

CONFLICT（内容）：“somefile”中的合并冲突
使用以前的分辨率解决了“somefile”。

您可以在此处找到more details，了解如何使用git rerere 处理冲突。