'；git日志'；与'不匹配；git日志标记..'；

我一直认为“git日志”是所有真相的来源，它真实地按时间顺序显示事情。但是我遇到了一个与git log range选项相矛盾的问题。我相信“tag..”选项将为我提供我所在的特定分支上的标记和头部之间的所有内容

例如，我使用git log--oneline--decoration并获取

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--一行--装饰

我会得到

af43779 (HEAD -> myBranch) commit o
5aeb672 commit n

但是，当我运行git log myTag--一行--装饰我得到的是：

df43779 (HEAD -> myBranch) commit o
5aeb672 commit n
060e7ee commit i
08a3fea commit d

假设

git log

说的是实话，那么range命令可能给我超出指定提交范围的提交的一些原因是什么

我知道更多的信息可能有助于具体回答这个问题，例如提交时间和分支复杂性信息。但我想我真正想知道的是更多的理论：git日志是以真实的时间顺序显示事情，还是不像看上去那么简单？“tag..”选项除了我对它所做的简单解释之外，还有其他作用吗？这些例子与我想的不一致的原因有哪些

---

换句话说，什么日志是“真正的日志”以及为什么？

git log myTag..

实际上是

git log myTag..HEAD

。它要求所有可从

HEAD

访问的提交，不包括那些可从

myTag

访问的提交。这回答了“自<代码>myTag以来我做了什么？”的问题，请参见“虚线范围符号”

o

和

n

很明显，它们在

myTag

之后。但是为什么

i

和

d

似乎在

myTag

之前呢？仅从您的

git日志

很难知道这一点

git log

提供了历史的线性视图，但git历史不是线性的。分支是真实的，提交可以以多种方式连接

默认情况下，

git log

以相反的时间顺序显示历史，同时确保家长和孩子的顺序正确。您必须运行

git log--graph

才能查看真正的连接。养成使用它或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

git历史不是线性的。不幸的是，默认情况下，

git log

构成了一个线性历史。添加

--graph

以查看提交是如何连接的，这就是“真实日志”。除了Schwern提到的（这是真实的）之外，

git log

还有另一个问题：它故意隐藏提交。例如，参见第5章的“查看”和“查看提交”部分（从第87页开始）。谢谢。我用

--graph

仔细检查了一遍，你是对的。就日志显示内容而言，我是否使用重定基址而不是合并有关系？@JCollier是的，非常重要

gitmergefoo

合并两个分支，如上所述

git-rebase-foo

在

foo

之上“移动”您的提交（实际上它会写入新的提交）。这就像假装你的提交一直写在

foo

之上。通常，

rebase

以更新分支及其父级，完成后，

merge

。看见