为什么我用git rebase 又出现同样的冲突？

Question

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

这是我们的分支情况：

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

鉴于 master 在不同时间产生的 2 个特征分支，我们现在想要合并这 2 个分支。我们想遵循 first rebase then merge 的做法，但是当我们将功能 A 变基到功能 B 时，我们会遇到冲突。这是预料之中的，因为这两个功能（和 master）在相同的区域都有变化。但奇怪的是，同样的冲突在git rebase --continue之后不断重复出现。这让我们抓狂，所以我们最终中止变基，并使用 git merge。事实证明，冲突其实很容易解决。

我的问题有两个：

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

SO 上的相关帖子：

Why do I have to resolve the same conflict over and over?
git rebase resolve conflicts again and again?

Answer 1

rebase 适合你的情况吗？

基于 Feature A 和 Feature B 似乎是 shared 分支的事实，我会说 no.

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

变基更改提交 ID（即 SHA-1 元数据的哈希值）。这意味着一旦你将重新设置的提交推送到 共享分支 ，它们将完全显示为 新提交 给任何在他们的本地 repo 上获取它们的人，即使它们仍然包含相同的更改。现在，如果有人在此期间在旧提交之上添加了新提交，他们将不得不移动它们。这造成了不必要的混乱。
当您合并 public 分支时，您经常想要拥有那些 合并提交 以便能够跟踪提交如何跨分支移动。该信息因变基而丢失。

引擎盖下发生了什么？

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

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

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

在配置文件(rerere.enabled true)中启用rerere后，每次发生合并冲突时，Git会记录冲突文件的状态在之前和之后合并它们。下次发生相同的冲突时——涉及合并双方完全相同的行的冲突——Git将自动应用它之前记录的相同解决方案。它还会在合并输出中让您了解它：

CONFLICT (content): Merge conflict in 'somefile'
Resolved 'somefile' using previous resolution.

在这里您可以找到 more details 如何使用 git rerere 处理冲突。

为什么我用git rebase 又出现同样的冲突？

Why does the same conflict reappear when I use git rebase?

git

merge

git-merge

git-rebase

rebase 适合你的情况吗？

引擎盖下发生了什么？

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