0

Git 存储库只有 master 并且每个人都在处理它(不要评判我,到目前为止是一件小事),默认情况下启用 Rebase。AFAIK git-rebase 重写历史,根据日期一一应用提交,并在此过程中需要时进入 MERGING 状态。但有一件事让我和团队很烦恼,历史有时不是线性的,请举几个例子:

在此处输入图像描述 在此处输入图像描述 在此处输入图像描述

这里会发生什么?或者我误解了 git-rebase 的工作原理?

4

1 回答 1

2

历史不是基于日期,而是基于 Git 所基于的底层图表。例如,您的历史记录可能如下所示:

                  branchA
                    ↓
* -- * -- * -- * -- *
      \
       * -- * -- *
                 ↑
              branchB

这些中的每一个都*代表您历史记录中的一次提交,但实际日期与图表中的位置完全无关。让我们用数字替换星星以显示它们创建的相对时间(稍后创建更大的数字):

                  branchA
                    ↓
1 -- 2 -- 4 -- 5 -- 8
      \
       3 -- 6 -- 7
                 ↑
              branchB

这是每个分支上的完美且“线性”(就时间而言)的历史。如果你记录历史branchA,你会得到8, 5, 4, 2, 1;因为branchB你会得到7, 6, 3, 2, 1

现在,如果你 rebasebranchBbranchA,Git 会重写这些提交branchB并将它们应用到branchA. 重写时,Git默认保持创作时间不变(但将提交时间重置为当前时间)。所以你会得到以下结果:

                  branchA
                    ↓
1 -- 2 -- 4 -- 5 -- 8 -- 3' -- 6' -- 7'
                                     ↑
                                  branchB

'这里表示它们实际上是与原始提交不同的提交,但它们确实具有相同的内容和作者时间)。

如果您现在查看 的日志branchB,您将获得以下信息:7', 6', 3', 8, 5, 4, 2, 1。这正是“时间悖论”的由来:您确实有一个完美的线性历史(本节的图表是线性的);但提交不一定按照它们最初创作的顺序。

这完全没问题,完全是设计使然:变基不应该完全重置提交,所以原始作者信息(谁做的,他们什么时候做的)仍然存在。

于 2016-09-29T09:06:01.427 回答