Git本身对日期没有语义。嗯，几乎没有。所以这取决于您。主要情况下，Git只显示具有作者日期的提交。如果您使用
git log --pretty=fuller，它将显示具有两个日期集的提交，并且就是这样。
唯一的例外情况发生在Git的
卑鄙的突起中有多个提交。
git log命令一次只能显示一个提交，但某种原因和方式会告诉您要显示
两个或多个提交。例如，假设您有以下内容:
C--D <-- br1
/
...--B
\
E--F <-- br2
当你运行
git log br1 br2或
git log --all时，你告诉Git：
展示提交D和F，然后从这里向后继续展示更早的提交。那么Git现在应该展示
D还是
F呢？它有两个选择。
默认情况下，Git会选择具有
较晚提交日期的那个。这有点不幸，因为它默认显示的日期是
作者日期。但你可以根据自己的需要进行处理。
git log命令有许多选项可以
更改它选择先展示
D还是
F的方式。其中包括
--author-date-order和
--topo-order。
一旦Git已经展示了
D或
F中的一个，它就会将
C或
E放入列表中。也就是说，它将展示的提交的父提交放入列表中。现在列表中显示
要么C F要么D E。与之前一样，它会根据你告诉它使用的规则集中的任何一个来选择，并展示它。
C或
D的父提交是
B，所以如果它刚展示了其中任何一个，现在就会将
B放入列表中。这样一遍遍地重复，直到列表收缩到只有一个条目为止——由于规则往往倾向于完成
C-D和
E-F链，然后再回到
B，因此这通常会很快发生。此外，一些规则（如
--topo-order）告诉Git，即使
B上的日期很奇怪，它也必须让它发生。
如果你发现Git以奇怪的顺序列出事物，请使用
git log --graph（也许还要加上
--oneline）。
--graph选项告诉
git log两件事：
绘制提交日志的粗略基于ASCII的文本图形。它是垂直定向的，而不是像我在StackOverflow帖子中通常做的那样水平定向的，但对于简单的图形或图形片段，这样做没问题。
在进行图形遍历时使用--topo-order。也就是说，一旦Git开始沿着C-D路径，它将在开始E-F路径之前完成该路径。
你可以用
--date-order或
--author-date-order等参数来覆盖默认的
--topo-order。
在合并时，你经常会看到这种非线性行为
请注意，无论提交的日期顺序如何，如果Git只有一个提交记录（例如你输入了git log br1以便从D开始），它只会显示那个提交记录。然后清空其要显示的提交列表，将D的父提交放入列表中。现在列表中列出了C，因此Git会显示C，然后再次清空列表，但是将B放入列表中。所以现在Git会显示B，然后再次清空列表，但是将B的父提交放入其中，以此类推。结果是一个简单的、线性的、向后的遍历。因此，如果没有合并提交，并且你从分支的末尾开始Git，你只会看到该分支：
...--o--o--o--tip <-- branch
但如果存在合并提交：
最初的回答：
C--D
/ \
...--o--o G--o--...--tip <-- branch
\ /
E--F
当Git显示
G时，它将
D和F都放入其列表中。现在你处于
两个提交在列表中的情况下，你需要考虑先显示哪个提交，就像使用
git log --all一样。
如果你使用
--first-parent强制Git不要跟随合并的
另一个分支，这个问题就会完全消失。有时这是好事，有时不是。如果你使用
--graph让Git画出图形，有时这很有帮助，但有时图形会变得非常复杂。
GitHub有时很烦人
虽然这与
Git无关，但值得在此提及的是，一旦Git
Hub开始在拉取请求中显示提交，Git
Hub开始使用自己的提交排序规则，而不是所有正常的Git规则。这些规则对GitHub的工作人员来说是有意义的，但对许多GitHub用户来说却不是那么合理。在这里，您需要与GitHub的工作人员交流。
