Intellij Idea Git Log 中的行是什么意思？

如何解决Intellij Idea Git Log 中的行是什么意思？

在Idea中按alt+9可以看到git日志窗口：

我看到那些点代表提交。这些线代表分支吗？如果是，如何判断每条线代表哪个分支？

我看到如果我将鼠标悬停在一行的某些部分，它的一部分会被突出显示，突出显示的部分是什么意思？如果我点击它，它会变成一条虚线。刚刚发生了什么？

有没有文章或者视频详细解释Idea git log window或者它使用的树状git log结构？我读过Idea's help page for git log window，但很少有关于这些行的字眼。

解决方法

是的，点是提交，线是分支。

要知道它指向哪个分支就足以查看下图所示的右侧窗格：

虚线仅代表您通过单击自己的提交选择的分支。

从您的屏幕截图中：当您看到灰点时，您可以看到提交的线性序列，没有任何合并，当您将鼠标悬停在它上面时会突出显示。

显然：单击悬停的行会隐藏此提交序列，并允许您专注于其他分支。
这条线变成虚线可能表示“在这条线的两端之间有隐藏的提交”。
单击虚线使这些提交再次可见。

我不知道IntelliJ如何选择可以折叠的序列；我的盲目猜测是：它可能会保留涉及合并的提交，以及由引用（分支、标签或远程分支）指向的提交。

您的部分问题是：

这些线代表分支吗？如果是，如何判断每条线代表哪个分支？

我在 two comments 中提到它们确实代表......我们很可能称之为分支：

branch 这个词在 Git 中往往会失去所有意义，所以除了作为 name 的修饰符之外，什么时候使用这个词还不是很清楚.如果我们说 master 是一个分支名称，而 develop 是一个 分支名称，等等，这些就很清楚了。从技术上讲，master 是 refs/heads/master 的简写，它是 ref 或 reference： 这是一种保存提交哈希 ID 的方法。¹
但是我们还需要一种方法来引用某些提交组。我们也倾向于称其为分支。
Git 提供远程跟踪名称，例如 origin/master。我们经常将找到的具有这样名称的提交集称为远程分支，而 Git 本身将这些东西称为远程跟踪分支名称，即使它们不是分支名称。²

我发现branch这个词被过度使用到了经常变得毫无意义的地步。但是这些线代表从提交到其他较早提交的链接。

我们通过从提交到提交来找到这些链接。当我们找到开始提交时，为了跟踪这些提交到提交的链接，使用分支名称，我们称之为分支。但这与分支名称不同，当我们观察它们如何随时间演变时，这里的问题就变得很清楚了。

让我们从一个只有三个提交的存储库开始，都在 master 或 main 上，并使用大写字母而不是 Git 真正用于它们的丑陋的大哈希 ID 来绘制这三个提交:

A <-B <-C   <--main

name main 包含三个提交的最后提交 C 的哈希 ID。提交 C 本身持有较早提交 B 的原始哈希 ID，提交 B 持有更早提交 A 的原始哈希 ID。我们说C 指向 B，B 指向 A——当然还有{{1 }} 本身指向 C。

Commit main 是第一个提交。没有更早的提交！所以提交 A 不指向任何地方。这使它成为根提交，并且 Git 可以在此处停止倒退。

我们现在向我们的提交集合添加一个新的分支名称。这个新名称也指向提交 A，如下所示：

我们选择一个名称与A--B--C <-- main,develop一起使用：

git checkout

我们现在通过名称 A--B--C <-- main,develop (HEAD) 使用提交 C。如果我们 develop 我们仍在使用 git checkout main，只是使用了不同的名称，但我们现在会坚持使用 C。

每次提交都保存每个文件的快照，始终冻结，以特殊的、只读的、仅限 Git 的、压缩的和去重形式保存。因此，develop 中的大多数文件可能与 C 中的文件相同，这一事实意味着 B 不会占用太多额外空间。如果 C 和 B 共享一个 100 MB 的文件而未更改，则该文件只有一个副本。

但是这些文件不能被其他任何东西使用。因此，C 必须将它们复制到一个可用的表单中。这就是您工作树中的内容：可用形式的副本。我们不会进一步讨论这个想法，但值得牢记并稍后重新审视。

无论如何，让我们现在以通常的方式进行新的提交 git checkout。提交 D 将像往常一样保存每个文件的（去重）快照，并将向后指向现有提交 D。当 Git 创建完 C 后，Git 会更新 当前分支名称，无论是什么——基于 D 的附件——指向 HEAD，像这样：

提交 A--B--C <-- main \ D <-- develop (HEAD) 现在在 A-B-C 上，对吗？而 main 仅在 D 上。好吧，最后部分是对的——但是提交 develop 也在 A-B-C 上。

您的查看者绘制的线条，将 develop 向后连接到 D 等等，不会告诉您什么分支，部分原因是分支机构无所谓。只有提交很重要。 Commit C 很重要，可以从两个名字中找到，所以它在两个分支上。将 C 向后链接到 C 的那一行现在代表两个分支。

我们可能会继续进行更多的提交：

很容易将它们视为独立的，就好像A--B--C <-- main \ D--E--F <-- develop (HEAD) 只有 develop。在 Git 中情况并非如此：分支名称仅对入门很重要。我们永远不知道什么时候该停止，除非我们遇到了像 D-E-F 这样的根提交。

为了让 Git 提前停止，我们使用了 A 之类的表达式。这是 main..develop 的简写。这使用了集合论：通过 develop ^main，我们找到 all 提交，然后通过 develop 我们找到 main 集合，我们减去排除的集合—— A-B-C 部分——来自整体。这给我们留下了 ^main，这是我们可能想要认为是“在分支 D-E-F”上的提交。但是为了达到目的，我们不得不说：在 develop 上的提交，减去在 develop 上的提交，因为 main 都在 两个分支上.

现在我们可以继续合并新提交到 A-B-C。当我们这样做时，我们可以让 Git 做一个快进，这根本不是合并：

main

结果：

git checkout main && git merge --ff-only develop

现在所有六个提交都在两个分支上。现在只有一条线，而不是两条线：我们不必为了让 A--B--C--D--E--F <-- develop,main (HEAD) 再指向 main 而分解我们的绘图。

或者，我们可以使用显式合并，或者先在 C 上进行提交：

main

导致：

git checkout main; (... make new commit ...); git merge develop

其中 commit A--B--C------G--H <-- main (HEAD) \ / D--E--F <-- develop 是 合并提交。 H 有两个向后的箭头：一个连接到较早的提交 H（如果我们成功了，否则直接 G），另一个指向提交 { {1}}。现在所有提交都在 C 上。合并提交 F only 在 main 上（至少现在是这样），但是因为它向后指向两者......无论我们称之为什么-的提交，所有这些提交都可达提交H，所以所有提交都“开启”main。有两行，但只有一个分支用于找到它们到目前为止。

当然还有名字H，它找到提交main，找到提交develop，依此类推，一直回到F。因此，提交 E 位于分支 A 上，就像以前一样。只是它现在也在分支 F 上。

但是：现在我们可以使用 develop 完全删除名称 main。当我们这样做时，我们只剩下这个：

develop

保留所有提交。还有两条线。但现在只涉及一个分支机构名称。

这就是为什么我喜欢说分支名称无关紧要——当然，除了找到一个提交。我们需要某种方法来找到提交git branch -d develop。只要我们有这个，我们也会找到所有较早的提交，因为它们是链接的，一个 - 或者对于合并提交 A--B--C------G--H <-- main (HEAD) \ / D--E--F，两个 - 一次，向后。

可视化工具中的线条代表这些联系。链接是分支，或者不是分支，或者是你喜欢的任何东西，这取决于你想如何查看它们。

¹我们还在 H 中得到了一个配置部分：

例如，分支名称不仅仅是提交哈希ID。但是这两个条目大多是静态的：例如，如果我们运行 .git/config 以更改 [branch "master"] remote = origin merge = refs/heads/master 和 remote 的上游设置，则merge和git branch --set-upstream-to设置会发生变化1}}。

²运行 master 然后 git checkout origin/master，我们看到这会产生 分离的 HEAD 状态，而不是 git status地位。因此，on branch origin/master——其完整拼写为 origin/master——不是一个分支名称。由于branch 这个词在Git 中被过度使用而受到严重打击，我认为将其称为远程跟踪分支名称 是个坏主意。短语远程跟踪名称同样适用于识别这是什么类型的名称。