git - 为什么我使用git rebase时，同样的冲突又出现了？

Question

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

这是我们的分支情况:

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

给定 2 个特征分支，这些分支在不同时间源自 master，我们现在想要 merge 这 2 个分支。我们想遵循先 rebase 然后 merge 的做法，但是当我们将特征 A rebase 到特征 B 时，我们会遇到冲突。这是预料之中的，因为这两个功能(和 master)在相同的区域都有变化。但奇怪的是，在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 似乎是共享分支的事实，我会说不 .

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

1. rebase 会更改提交 ID(即元数据的 SHA-1 哈希)。这意味着，一旦您将重新设置的提交推送到共享分支，它们将作为完全新提交显示给任何在本地存储库中获取它们的人，即使它们仍然包含同样的变化。现在，如果有人在此期间在旧提交之上添加了新提交，他们将不得不移动它们。这造成了不必要的困惑。

2. merge 公共(public)分支时，您通常希望拥有那些 merge 提交，以便能够跟踪提交如何跨分支移动。 rebase 会丢失该信息。

引擎盖下发生了什么？

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

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

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

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

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

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