git - merge 和 rebase 如何工作？

Question

我试图从数学中的集合运算的角度理解 merge 和 rebase 的作用。

在下文中，“-”表示diff(类似于数学中的取集差，但“A-B”表示在A中不在B中，减去B中不在A中的)， “+”表示patch(即在数学中采用不相交的并集。我之前没有使用过patch，所以我不确定)。

1. 来自 Chacon 的 Pro Git，

   

   最近的共同祖先C2在这个中的作用是什么 merge ？

   C5 = (C4-C2) + (C3-C2) + C2 是否正确？

2. 为了 rebase 而不是 merge :

   

   C4' = (C4-C2) + C3 是否正确？

   那么 merge 的 C5 和 rebase 的 C4' 有相同的内容吗？

3. 来自 Loeliger 的 Git 版本控制

   

   W'、X'、Y'、Z'是如何生成的？

Answer 1

您无法真正正确地使用“差异”和“补丁”语义来解释 Git。原因是 Git 不跟踪更改；它跟踪内容。当你提交 A与父提交 B ，然后对于 Git，A不是B之间的区别和 A ，即从 B 获得所需的更改至 A ，但A的实际内容.您可以自己进行提交，此时您拥有重建存储库的一切。

因此，我不会遵循您的“提交算法”，而是尝试用文字解释每个案例。

1. C5 是与两个父级 C3 和 C4 的 merge 提交，它们都以 C2 作为父级。所以假设没有冲突，并且 Git 能够自行解决整个 merge ，那么 C5 将包含以下两个等价表达式所表达的内容:

   • C3 应用了可以让您从 C2 升级到 C4 的补丁。
   • C4 应用了可以让您从 C2 升级到 C3 的补丁。

   所以在某种程度上，您可以用您的公式来制定它。

2. rebase 基本上会使您处于完全相同的情况。唯一的区别是它实际上重写了它 rebase 的提交，将它们的更改(补丁)重新应用到另一个提交。所以结果 C4将具有与 C5 相同的内容来自 (1).

   根据您的“算术”，我通常会说 (C3-C2) + C2 = C3 .所以这两个公式在这里也是等价的。

3. 如上所述，rebase 只是将提交补丁重新应用到另一个父级上。 Git 正在编写包含与原始提交相同的更改 的新提交，但这些新提交应用于不同的父级。

   所以如果你想得到它的公式，它可能看起来像这样:

   W' = E  + (W - B)        (the patch from B to W, applied on E)
   X' = W' + (X - W)        (the patch from W to X, applied on W')
   Y' = X' + (Y - X)        (the patch from X to Y, applied on X')
   Z' = Y' + (Z - Y)        (the patch from Y to Z, applied on Y')
   

   所以 W 的基数更改为 E而不是 B ，并且所有后续提交都刚刚更新以跟进该新提交 W'相反。

   但结果又是Z'与 merge E 的 merge 提交具有相同的内容和 Z会有。

这一切都给我们留下了一个问题:如果 merge 和 rebase 产生相同的内容，那么两者之间有什么区别？由于您不会以两种方式丢失提交( rebase 将创建新的提交对象，但那些将保留所有原始信息)，基本上这都是关于改变历史的样子:

merge 创建一个 merge 提交，允许清楚地看到历史在哪里 fork (分支创建的地方)以及它再次 merge 的地方。这很好，因为您可以跟踪确切的发展。但它也可能变得困惑，特别是如果最终 merge 多次，或者如果您有多个并发分支线。

另一方面， rebase 使得历史变平。它“伪装”它，使一切都是线性发展，一切都接踵而至。因为你总是 rebase 一个完整的分支，你把相关的提交放在一起，所以你仍然可以看到属于彼此的东西，但是你丢失了任何分支信息。此外，您正在创建新的提交对象，这将破坏已经知道这些提交对象的每个人的存储库(这就是为什么您永远不应该对已发布的提交进行 rebase )。

两种方式各有利弊。这在很大程度上取决于存储库工作流程和个人偏好。