Git存储库只有master并且每个人都在使用它(不要判断我,到目前为止是一件小事),默认启用Rebase。 AFAIK git-rebase根据日期逐个重写提交申请的历史记录,并在此过程中需要时进入MERGING状态。但有一件事让我和团队感到烦恼,历史有时不是线性的,请遵循一些例子:
这里会发生什么?或者我误解了git-rebase是如何工作的?
答案 0 :(得分: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
。
现在,如果您将branchB
重新定位到branchA
,Git会在branchB
上重写这些提交并将其应用到branchA
。在重写时,Git 默认情况下保持创作时间不变(但将提交时间重置为当前时间)。所以你会得到以下结果:
branchA
↓
1 -- 2 -- 4 -- 5 -- 8 -- 3' -- 6' -- 7'
↑
branchB
(这里'
表示它们实际上与原始提交不同,但它们具有相同的内容和作者时间。)
如果您现在查看branchB
的日志,您将获得以下内容:7', 6', 3', 8, 5, 4, 2, 1
。而这正是“时间悖论”的来源:你确实有一个完美的线性历史(这一部分的图形是线性的);但是提交不一定按照他们最初创作的顺序。
这完全没错,完全按照设计:重新定位不应该完全重置提交,所以原始作者信息(谁做了,他们什么时候做的)仍然在那里。