git后台合并什么？

Question

我知道 $ git rebase 在后台做什么。假设这样：

A -- B -- C
      \
       D -- E

$ git rebase 会记住我们在 e 中所做的所有更改（基础是 b）并将它们应用到基础 c 中。所以结果是：

A -- B -- C -- D' -- E'

现在我想知道，$ git merge在后台做了什么？其实有趣的部分是"why merge has a possibility of conflict but rebase doesn't"？

Answer 1

to avoid conflict is using rebase before merge

确实如此：为了避免在您必须将分支合并到其上游分支时发生冲突（例如，在推送时）：从您的架构来看，合并将是一个快进的合并。

此外，您可以训练 rebase 记住您可能必须执行的冲突解决方案，这意味着您可以多次 rebase 而不必重新解决所有相同的冲突。 See git rerere (works even if you did not initially activate rerere, or you can do a manual retraining).

这就是我推荐 rebasing (pull --rebase) before pushing (also in this answer 的原因）：在推回本地提交之前，先在本地（在本地存储库中）解决可能的合并冲突。

但是请不要误会，rebase 将在另一个分支 using a merge strategy 之上重新应用您的每个提交。所以可能会发生合并冲突。
这个will be better expressed in Git 2.14.

Answer 2

冲突与提交无关，而与树比较有关。

如果您对分支 1 中的文件 A、B 和 C 进行了一些更改，将更改存储起来并移至分支 2，其中 B 的内容不同，您将在文件 B 中遇到冲突。尽管你没有做出任何承诺。

合并和变基以不同的方式工作。 merge 和 rebase 之间最根本的区别之一是合并提交有多个父提交——如果你想从合并提交返回，你必须指定父编号。

合并提交的方式是，如果要合并的分支有4个提交，例如，合并提交在主分支之上进行，更改等于4中更改的总和提交（类似于压缩提交时得到的）。如果你得到冲突，你会立即得到所有更改的所有冲突。

变基不同 - 更改是逐个提交应用的。如果提交 2 中存在冲突，则必须在应用 3 之前解决它们。提交的 ID 也已更改，以指示这些是重新设置的提交。

git后台合并什么？

What does git merge in the background?

git

merge

rebase