1

就时间而言，Git 快进合并是 FORWARD。指针从旧提交到新提交。

示例（通过 ffwd 合并主指针从提交 D 移动到提交 G）：

在快进合并之前：

                  master
                    |
        A<--B<--B<--D<--E<--F<--G
                                |
                           new_branch

快进合并后：

                              master
                                |
        A<--B<--B<--D<--E<--F<--G
                                |
                           new_branch

但是，由于提交指针从较新指向较旧，因此严格按照这些指针，分支指针向后移动......提交指针上游。所以从这个意义上说，它可以被标记为快速反向合并。上游（ProGit 书中关于合并的章节中的术语）指的是逆流，上游，因此将上游流解释为快进可能会使新手感到困惑。所以是：

提交指针的上游。

在提交时间方面前进。

这种推理有意义吗？

4

2 回答 2

2

仅当提交遵循箭头的路径时，这才是正确的。

我认为这让你感到困惑。记住，箭头指向你来自哪里，而不是你要去哪里。

主指针及时向前移动，沿着分支向前移动。请记住，HEAD 位于分支的顶端。任何时候你向 HEAD 移动（假设它没有被向后移动），你都会及时向前并提交。

现在，如果你想把它想象成一个链表，那么是的，通常 A 是头部，G 是尾部，除了......我们知道在 Git 中我们的 HEAD 指向 G。除此之外，我认为新手通常不会在这么低的层次上看待它并尝试将数据结构概念应用于它。

你想多了。

于 2012-05-30T15:33:40.520 回答
0

不，它不会移动master到“G”。它只是从“G”开始，从“D”开始。master只是一个名称/标签的东西（称为ref）。它在合并后更新，而不是分步“移动”。

要理解这一点，您可以尝试合并冲突。当合并等待手动解析时，分支仍然指向它们的旧提交。只是结帐树和索引处于不确定状态。

更新： 也许你可以这样想：

  1. 找到合并基git merge-base D G，这是 G
  2. 在 G 处创建一个假的临时分支（不是真正的分支，但让我们暂时假设一下）。
  3. ff 假分支到 D。
  4. 将假分支重命名为master，覆盖旧分支。
于 2012-05-30T15:33:19.227 回答