关于Git的合并与变革

Question

以上是合并和转换的结果。

我的问题是，在最终状态下， C5 和 C3'相同吗？

或者说，git rebase等于git merge +删除 C3 ？

Answer 1

示例不是很好，因为它只考虑一个提交（合并或重新绑定），让您觉得结果提交是相似的。通常，rebase将添加多个提交，而合并将最多添加一个（快进合并添加无）。

此外，只要没有要解决的冲突，或者每次以相同的方式解决所说的冲突，C3'和C5的最终内容将会是相同的，但他们仍然是不同的提交（因为C3'和C5有不同的父母，他们也会有不同的哈希，这一事实在下面的插图中更明显）。相应地，每个记录的历史记录是不同的。对于rebase的注释，历史是线性的，而对于合并，它是lattice。

在合并/重新定位 多次提交 时，请考虑相同的问题，如Mark Lodato的“A Visual Git Reference”所示。您将看到最终结果相当不同。

git checkout master
git merge other # update master with tip of branch 'other' changes

你只接受：

• 当前提交（由于您在主人身上，因此下面是ed489），
• 分支其他的最新提交（这是一个快照，表示在“other”中分支时的代理的完整内容，而不是delta）
• 他们的共同祖先（b325c），执行three-way merge。

有关此图表中工作目录和阶段的含义，请注意箭头转到三向合并，然后转到工作目录和阶段。工作目录表示您看到（在您的硬盘上）的所有文件，其中一些文件由于三向合并而被更改。该阶段保存由三向合并更改的文件，然后用于创建新提交（f8bc5）。

这与rebase非常不同，后者努力在目标分支的顶部重新应用每个分支的提交：

git checkout topic # this time we are on topic
git rebase master  # means: recreate every topic commits on top of master
                           at the end, we are still on (new) 'topic' branch

  

上面的命令接受“topic”中但不在master中的所有提交（即169a6和2c33a），将它们重播到{ {1}} ，然后将分支头移动到新的提示。请注意，如果不再引用旧提交，则最终将[最终]进行垃圾回收。

重新引用使用工作目录和暂存区域，因为它重放提交（将更改应用于工作目录，将更改添加到暂存区域，提交暂存的更改，重复）。完成所有这些后，重新分支的分支头被设置为最后一个新提交（f7e63）。

---

另外2个差异：

• 合并和rebase服务于不同的工作流程：请参阅“git merge vs. rebase”
• “我们的”和“他们的”在合并和变基之间是不同的：“Why is the meaning of “ours” and “theirs” reversed”

Answer 2

没有。 C5和C3'将有不同的父提交，这意味着它们本身会有所不同。

如果您询问C5和C3'引用的根树是否相同，那么是（假设任何冲突都以相同的方式解决）。换句话说，“包含在”两个提交中的文件树将是相同的。

Answer 3

如果你只查看提交的内容（即不是他们的父母的内容）那么C5和C3'都包含相同的东西（假设没有合并冲突或其他需要手动更改的东西）。所以有人可能会认为它与删除C3一样，对于“删除C3”的某些定义。但是在Git中，不可能删除任何提交（所有提交都是不可变的），因此没有为Git定义从树中删除提交的操作。