第一次提交的git log是否是分支的当前提交？
我使用git log列出提交：
$ git log
commit 75a80c128ea8b28f946b1bd55afa65cc1802bee5
Author: lio <lio@126.com>
Date: Wed May 9 22:00:35 2018 +0800
2018-05-09-11
commit a57089b64890e5602a39dc33dc1f07d620d8a870
Merge: c57feb6 9116e2b
Author: lio <lio@126.com>
Date: Wed May 9 21:52:13 2018 +0800
Merge branch 'master' of 103.200.32.76:/home/ldl/repo/Qiyun02
commit c57feb677a170d786756c97cb71f6225ba9e6774
Author: lio <lio@126.com>
Date: Wed May 9 21:48:50 2018 +0800
2018-05-09-10
commit 9116e2b15605590a2db437bee2f7b83f3f9271ff
Author: root <root@www.lio.xyz>
Date: Wed May 9 13:47:28 2018 +0800
...
第一次提交75a80c128ea8b28f946b1bd55afa65cc1802bee5是否是分支的当前提交？
答案 0 :(得分：0)
是的，我想，如果你问的是它是否是最新的提交。
git log命令显示当前分支的提交历史记录。
例如，如果你有两个分支，掌握和开发。开发分支是在master分支之前的一个提交，而较新的提交是＃34;奇妙的提交＆＃34;。当您签出主分支和git log时，它将显示主分支的提交历史记录，如
intital commit -> commit1
然后，如果你结帐开发分支和git log，它将显示
intital commit -> commit1 -> fantastic commit
但是您无法在当前分支的HEAD提交之后看到更新的提交。
我建议你使用这个别名。它展示了一个非常漂亮的git历史。只需将其添加到.gitconfig即可。
[alias]
log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
答案 1 :(得分：0)
正确而准确的答案有点棘手，但最直接的答案是＆＃34;是＆＃34;。更具体地说：
[在
git log输出中，是第一次提交[显示]分支的当前提交？
是的，是的。
完整答案复杂的原因是git log一次显示一个提交，有时 git log有两个要同时显示的提交。它不能这样做，所以它必须选择其中之一并显示出来。但是，运行：
git log
相当于运行：
git log HEAD
通过检查当前提交告诉git log开始。如果名称HEAD附加到分支名称 - 即，如果git status会对某些 B 说on branch B，那么当前提交是最尖端的提交分支 B 。总是只有 1 一个当前提交：永远不会有两个当前提交，只能有一个。因此，对于git log HEAD或git log没有其他参数，Git会从当前一次提交开始。
1 好吧，几乎总是。这是一个必要的特例。假设您创建了一个空存储库，其中还有 no 提交。哪个提交将是当前提交？ 还没有任何提交，因此Git需要一种方法来允许 no 提交为当前。一旦提交，Git将选择其中一个作为最新版本。
您可以使用git checkout --orphan触发特殊情况并返回 no 当前提交，但这样就完成了一组案例：那里有一个当前提交 - 通常情况 - 或者 no 当前提交，在新的空存储库中或在此特殊git checkout --orphan模式期间（两者都使用相同的底层技巧以允许没有当前提交情况。）
如您所见，每个提交都附有日期和时间戳：
Date: Wed May 9 22:00:35 2018 +0800
实际上，每次提交都有两个这些附加的时间戳。要查看两者，请运行git log --pretty=fuller。但是，git log命令不直接使用这些日期和时间戳。更重要的是每个提交都有哈希ID ，大多数提交列出一个或有时两个其他提交哈希ID。你可以在这里看到其中一些：
commit a57089b64890e5602a39dc33dc1f07d620d8a870
Merge: c57feb6 9116e2b
Author: ...
Date: ...
注意明显随机的数字和字母串a57089b64890e5602a39dc33dc1f07d620d8a870。这是此特定提交的哈希ID。在其下方是单词Merge:以及另外两个数字和字母串：c57feb6和9116e2b。这些是提交a57089b...的两个父提交的缩短哈希ID。
第一个大丑陋的哈希ID a57089b...是提交的真实，真实的内部Git名称。这就是Git访问提交的方式。但是为了找到那个丑陋的哈希ID，Git需要某种起点 - 或者更确切地说，结束点。
Git开始的结束点是提交75a80c128ea8b28f946b1bd55afa65cc1802bee5。查看git log输出的第一行，并在那里查看哈希ID。 Git 通过读取当前的分支名称来找到<丑陋的哈希ID ，例如master（您实际检查过的任何分支）。 name 存储哈希ID。
同时，提交75a80c1...存储，作为其（单个）父哈希ID，合并提交 a57089b...的ID。因此，在显示您提交75a80c1...后，git log继续提交a57089b。它显示提交为显示的第二个提交。但是现在Git有两个提交显示：c57feb6和9116e2b。
git log命令必须选择要显示的这两个提交之一。它通过将两个提交放入priority queue来实现。然后，它从此队列中选择具有最高优先级的提交。但是哪个提交是那个？那么，这取决于您传递给git log的选项。 默认是按CommitDate时间戳对队列的内容进行排序（再次使用git log --pretty=fuller来查看这些时间戳），旧的提交具有更高的时间戳优先于新的。
您在普通Date:输出中看到的git log不是CommitDate，而是AuthorDate。要使git log按此日期排序，请使用--author-date-order（但请注意，这也意味着拓扑排序）。
在任何情况下，这里的关键点是，只要git log有多个提交显示，实际时间戳就会重要。在此之前，优先级队列中只有一个提交：Git从队列中删除提交，显示它，然后将提交的父级放入队列，给Git提交一个提交。 Git删除一个提交，显示它，将父级放入，等等。当您点击合并提交时，此进程自动将至少两个提交放入队列。
但是如果你运行git log branch1 branch2 branch3，Git首先将三个提交放入优先级队列。 2 现在Git有多个提交要显示，并且再次，时间戳值生效。这也适用于您运行git log --all或git log --branches的情况，只要有多个引用从git log开始。
因此这里的规则是：只要你从HEAD开始，就会先看到当前的提交。这是因为只有一个当前提交，所以＆＃39;只有一个提交首先显示，即使它是合并提交。
2 这假设三个分支名称指向三个不同的提交，这不一定是真的 - 但这是后来要担心的复杂因素。