我一直认为'git log'是所有真相的源泉,按时间顺序显示事物。但是我遇到了与git log range选项的矛盾。我相信'tag ..'选项会给我标签和HEAD在我所在的特定分支之间的所有内容。
例如,我使用git log --oneline --decorate
并获得
df43779 (HEAD -> myBranch) commit o
5aeb672 commit n
34cc390 (tag: myTag) commit k
060e7ee commit i
7b6607a commit f
08a3fea commit d
467aea3 commit b
aa4c5dd commit a
而且我希望当我做git log myTag.. --oneline --decorate
时我会得到
af43779 (HEAD -> myBranch) commit o
5aeb672 commit n
但是,当我运行git log myTag.. --oneline --decorate
时,我得到的是:
df43779 (HEAD -> myBranch) commit o
5aeb672 commit n
060e7ee commit i
08a3fea commit d
假设git log
说的是实话,为什么我的range命令可能给我提交超出我指定的提交范围的原因是什么?
我知道更多信息可能对回答这个问题很有帮助,例如提交时间和分支复杂性信息。但我想我真正想知道的是更理论化的东西:git log是按真正的时间顺序展示的,还是不像看起来那么简单?并且'标签..'选项除了我对它的作用的简单解释之外还做了什么吗?我认为这些例子不符合的原因是什么?
换句话说,什么日志是“真正的日志”,为什么?
git log myTag..
真的是git log myTag..HEAD
。它要求从HEAD
可以获得的所有提交,不包括从myTag
可以到达的提交。这回答了“自myTag
以来我做了什么?”的问题。请参阅gitrevisions“Dotted Range Notations”。
o
和n
很明显,他们是在myTag
之后。但为什么i
和d
似乎在myTag
之前?很难从你的git log
知道。 git log
呈现历史的线性视图,但Git历史不是线性的。分支是真实的,提交可以以多种方式连接。
默认情况下,git log
以反向时间顺序呈现历史,同时确保父母和孩子的顺序也正确。你必须运行git log --graph
才能看到真正的联系。养成使用它的习惯,或者像tig
这样的Git日志可视化工具。
这是一种可能发生的方式......
o HEAD
|
n
|\
myTag k |
| i
f |
| d
|/
b
|
a
反向日期顺序仍然是o-n-k-i-f-d-b-a
,但现在我们看到一个分支在b
制作并合并在n
。 myTag
在它之前看不到o-n
,但它也在另一个分支中看不到i-d
。 myTag
和HEAD
的历史在b
回归。所以git log myTag..HEAD
给你o-n-i-d
。