为什么git rebase需要3向合并? [英] Why does git rebase require a 3-way merge?

问题描述

我试图弄清楚为什么要重新设置基准需要进行三向合并.例如，如果我们有

A1 - A2
 \
  B1   

我已经签出了B1，我想执行:

git rebase A2

为什么git合并A2，B1和A1?为什么A2和B1不够用?我的意思是，作为提交的A2和B1是否不包含树的完整当前快照?

解决方案

要执行合并，Git需要找出自共同祖先(A1)以来两个分支中到底发生了什么.正确地说，Git存储提交/树的快照，以便获得实际的变更集，它必须将A2与A1进行比较并将B1与A1进行比较，然后合并这些单独的变更集. /p>

相同的事情发生在rebase中.要在B1上应用A2的更改集，我们首先需要根据A1和A2之间的差异来计算该更改集.然后我们可以将其应用于B1.您可以将重新部署视为类似于自动生成补丁文件的工具.首先，它会从旧分支中生成所有这些补丁文件，然后将其应用到当前HEAD.

因此，我们需要所有这三个提交来实际计算差异，因为我们无法仅通过查看该提交来弄清提交中发生了什么.

I'm trying to figure out why rebase requires a three-way merge. For instance, if we have

A1 - A2
 \
  B1   

And I've checked out B1, and I want to perform:

git rebase A2

why does git merge A2, B1 AND A1? Why wouldn't A2 and B1 suffice? I mean, don't A2 and B1 as commit contain the complete current snapshot of the tree?

解决方案

To perform a merge, Git needs to find out, what exactly happened in the two branches since the common ancestor (A1). As you have said correctly, Git stores snapshots of the commits/trees so to get an actual change set, it has to compare A2 to A1 and B1 to A1 and then merge those individual change sets.

The same thing happens in a rebase. To apply the change set of A2 on B1, we first need to calculate that change set from the differences between A1 and A2. And then we can apply that to B1. You can think of a rebase as something similar to an automated generation of patch files. First it generates all those patch files from the old branch and applies them then to the current HEAD.

So, we need all those three commits to actually calculate the differences, as we cannot figure out what happened in a commit just by looking at that commit.

这篇关于为什么git rebase需要3向合并?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！