将中间分支中的更改与 DVCS 合并

Question

我使用 Plastic SCM 已经有一段时间了，但直到最近才发现我关于分支机构变更集工作方式的思维模型存在缺陷。

考虑这个简单的场景：

• 假设我有一个带有文件 foo.txt 的分支 A，
• 我将 A 的最新更改集分支到子分支 B。
• 我将工作区切换到 B 并签出 foo.txt 并进行一些更改，我将其签入。
• 我将 B 的最后一个更改集分支到 C。
• 我尝试将 C 合并到 A

简而言之：A 分支到 B，更改 foo.txt 在 B 中，分支到 C，将 C 合并到 A。

令我惊讶的是B 中间分支中对 foo.txt 所做的更改被忽略，因为我没有对 C 中的 foo.txt 进行更改。所以从 C 合并到 A 后，A 包含分支出 B 之前的原始 foo.txt。

我本希望在执行从 C 到 A 的完全合并时合并 B 中的中间更改，但显然我对分支中更改集的理解是错误的。当更改神秘地丢失时，这会不时地导致相当多的清理工作。

Git 和 Mercurial 或其他 DVCS 的行为是否相似？

编辑：

塑料版本 <= 3 仅合并源分支中的更改，而不合并中间分支。

Plastic >= 4 合并整个分支路径。

Answer 1

Git 不是这样工作的。在 Git 中，分支实际上只是指向一系列中最后一次提交的指针。当您在该分支上进行新提交时，指针会向前移动到新提交。

因此，当您从现有分支创建新分支时，您现在只有两个指向同一提交的指针。两个分支都有相同的历史。

您所讨论的场景在 Git 中看起来像这样：

           A
           ↓
a1 ← a2 ← a3    B
             ↖  ↓
               a4   C
                 ↖  ↓
                   a5

在 Git 中，您只有一系列提交，但其中一些碰巧有指向它们的分支标签。 A 指向 a3（它知道 a2 是它的父级）； B 指向 a4，它以 a3 作为其父级，依此类推。因此，默认情况下，如果您将 C 合并到 A 中，Git 会执行“快进”合并（这仅意味着 A 没有更改），您会得到以下结果：

                B    A, C
                ↓    ↓
a1 ← a2 ← a3 ← a4 ← a5

现在您可以摆脱如果你愿意的话，B 可以改变。一种方法是使用交互式变基：

git rebase -i

这会向您显示提交列表，您只需从该列表中删除 B 提交即可。 Git 会在没有该提交的情况下重放您的提交。另一种方法是从 A 开始，然后将

git cherry-pick a5

a5 更改作为 a3 之后的下一个更改集。但这两件事都是你必须做的特殊事情。默认情况下，B 将包含在合并中。

Answer 2

Mercurial 对分支的工作方式与 git 不同。在 Mercurial 中，变更集的分支名称实际上是变更集的一部分。书签的行为有点类似于 git 的分支。仍然存在差异，这篇文章很好地涵盖了 hg 书签和 git 分支。

无论是使用 Mercurial 书签还是命名分支（甚至只是匿名分支），您仍然会得到：

@__    merged C into A (branch A again)
|  \
|   o  add c.txt (branch C; a commit is necessary to start named branch)
|  / 
| o    appended to a.txt (branch B)
|/
o      added a.txt (branch A)

合并后，A 包含：在第二个变更集中完成附加文本的 a.txt（以及添加的 c.txt）在第三个）。