如何理解git log --graph

Question

我对图形git log的输出很困惑.

我明白每个都*意味着提交,无论是分歧,共同提交还是合并提交.我明白管道意味着分支.

我们来看一个简单的图形日志:

首先,红色管道(最左手的那个)代表哪个分支？我不认为这是我当前的分支,因为在我结账到其他分支后,图表看起来是一样的.此外,它也不代表主分支.

第二,如果最左手的分支代表一个分支,为什么它在提交"0e5b5"后会改变颜色？

我搜索了一个关于如何读取git log graph的教程,不幸的是,我什么也没得到.如果有关于此主题的一些很棒的教程,请随时分享.

Answer 1

Git 从当前提交开始工作，查看祖先。分支不是“实体”，它们是（移动的）引用。git log（或具有不同配色方案但类似于 git log --graph 或 tig 的 gitk）无法知道当前分支是分支 A 还是分支 B 的后代。它只知道父分支。来自 man git-log：

   git log -p -m --first-parent
       Shows the history including change diffs, but only from the "main 
       branch"   perspective, skipping commits that come from merged
       branches, and showing full diffs of changes introduced by the merges. 
       This makes sense only when following a strict policy of merging
       all topic branches when staying on a single integration branch.

会在一定程度上解决您的担忧。git log 默认使用当前签出的提交作为参考（等同于执行git log HEAD

虽然我个人认为 git 的手册页很清楚，但您可能想看看 gitk 或 tig。前者是图形界面，后者是类似终端​​的最小化 gitk 工具。我根据我想做的事情使用两者。

Answer 2

在 Git 2.25（2020 年第一季度）中，“ git log --graph”的实现得到了重构，然后它的输出得到了简化。

在某些情况下，这反过来可以修复颜色。
下面提供了有关如何使用 管理颜色和边缘的说明git log --graph。

请参阅Denton Liu ( ) 的commit d784d97（2019 年 11 月 12 日）。 请参阅提交 bbb13e8，提交 92beecc，Denton-L
提交479db18，提交0195285，提交d62893e，提交0f0f389，提交458152c，提交ee7abb5，提交46ba2ab，提交a551fd5，提交9157a2a，提交210179a，提交fbccf25（2019年10月15日）由詹姆斯Coglan（ ）jcoglan。
^{（由Junio C Hamanogitster合并-- --在提交 0be5caf，2019 年 12 月 1 日）}

graph：修复章鱼破折号的着色

^{签字人： James Coglan}

在04005834ed（“ log：修复某些章鱼合并形状的着色”，2018 年 9 月 1 日，Git v2.20.0-rc0 --合并在第 6 批中列出）中，修复了章鱼合并后破折号的着色。
它区分了所有父项引入新列的情况与第一个父项合并到现有列的情况：

| *-.           | *-.
| |\ \          | |\ \
| | | |         |/ / /

后一种情况意味着new_columns与前一种情况相比，合并父项的列从数组左侧的一个位置开始。

然而，只有当提交的父项在映射到可视列时保持有序时，实现才有效，因为我们在new_columns打印 dashes 时通过迭代获得颜色。
通常，提交的父项可以任意与现有列合并，并在此过程中更改它们的顺序。

例如，在下图中，每列的编号表示每列中出现哪个提交父项。

| | *---.
| | |\ \ \
| | |/ / /
| |/| | /
| |_|_|/
|/| | |
3 1 0 2

如果列是彩色的（红色、绿色、黄色、蓝色），那么短划线当前将被着色为黄色和蓝色，而它们应该是蓝色和红色。

为了解决这个问题，我们需要查找mapping数组中的每一列，它在GRAPH_COLLAPSING状态之前指示每个可视列中显示哪个逻辑列。
此实现更简单，因为它没有任何边缘情况，并且它还处理现在如何显示左偏第一父项：

| *-.
|/|\ \
| | | |
0 1 2 3

第一个破折号的颜色始终mapping是提交符号右侧两列中的颜色。因为提交是在所有边折叠在一起并且可视列与逻辑列匹配后显示的，所以我们可以使用commit_index.

关于边缘（仍然使用 Git 2.25，2020 年第一季度）：

graph：提交行上折叠边缘的平滑外观

^{签字人： James Coglan}

当图形包含正在向左折叠的边，但这些边穿过提交线时，效果是边具有锯齿状外观：

*
|\
| *
|  \
*-. \
|\ \ \
| | * |
| * | |
| |/ /
* | |
|/ /
* |
|/
*

我们已经采取措施在边缘扩展时平滑这样的边缘；当一条边出现在GRAPH_COMMIT紧接一行的合并提交标记的右侧时GRAPH_POST_MERGE，我们将其渲染为\：

* \
|\ \
| * \
| |\ \

我们可以对折叠边进行类似的改进，使它们更容易跟踪并给整个图形一种增加对称性的感觉：

*
|\
| *
|  \
*-. \
|\ \ \
| | * |
| * | |
| |/ /
* / /
|/ /
* /
|/
*

为了做到这一点，我们为GRAPH_COMMIT紧跟在一个GRAPH_COLLAPSING线的线上的。
通过在mapping阵列中保留用于渲染GRAPH_COLLAPSING线的old_mapping阵列副本，我们可以确定一条边正在通过GRAPH_COMMIT线塌陷，应该进行平滑处理。

更普遍：

graph：左偏合并的提交和合并后行

^{签字人： James Coglan}

在引入“左偏”合并（即第一个父级与其左侧的另一条边融合的合并）之后，我们在提交和合并后行的显示中还有一些边缘情况需要处理。

当前图形代码处理以下情况，即*提交行上出现在提交 ( )右侧的边。

2 路合并通常后跟垂直线：

| | |
| * |
| |\ \

章鱼合并（超过两个父母）总是跟随向右倾斜的边缘：

| |  \          | |    \
| *-. \         | *---. \
| |\ \ \        | |\ \ \ \

如果提交行紧跟在与当前提交相同的列中或左侧任何列中的提交的合并后行，则 2 向合并后跟右斜边：

| *             | * |
| |\            | |\ \
| * \           | | * \
| |\ \          | | |\ \

此提交为提交行引入了以下新情况。如果 2 路合并向左倾斜，则其右侧的边缘始终是垂直线，即使提交遵循合并后的线：

| | |           | |\
| * |           | * |
|/| |           |/| |

具有 3 个向左倾斜的父项的提交后跟垂直边缘：

| | |
| * |
|/|\ \

如果在合并后行之后立即出现 3 向左倾斜合并提交，那么它可能会跟随右倾斜边缘，就像不倾斜的 2 向合并一样。

| |\
| * \
|/|\ \

Octopus 与 4 个或更多向左倾斜的父级合并将始终跟随右倾斜边缘，因为现有列需要围绕合并展开。

| |  \
| *-. \
|/|\ \ \

在合并后的行上，通常所有边沿当前提交斜率向右：

| * | |
| |\ \ \

但是，如果提交是向左倾斜的 2 向合并，则其右侧的边缘保持垂直。
我们还需要在从提交标记下降的垂直线之后显示一个空格，而该行通常后跟一个反斜杠。

| * | |
|/| | |

如果向左倾斜的合并有 2 个以上的父项，则其右侧的边缘仍然倾斜，因为它们围绕合并引入的边缘弯曲。

| * | |
|/|\ \ \

为了处理这些新情况，我们不仅需要知道每个提交有多少个父项，还需要知道它向显示添加了多少新列；这个数量记录在edges_added当前提交的prev_edges_added字段中，以及先前提交的字段中。

这里，“列”指的是可视列，而不是columns数组的逻辑列。
这是因为即使所有提交的父项最终都与现有边缘融合，它们最初会在这些边缘崩溃之前在提交和后合并行中引入不同的边缘。

例如，第 2 和第 3 个父项与现有边融合的 3 路合并仍会引入 2 个视觉列，这些列会影响其右侧边的显示。

| | |  \
| | *-. \
| | |\ \ \
| |_|/ / /
|/| | / /
| | |/ /
| |/| |
| | | |

此合并不会引入任何逻辑列；一旦所有边缘都折叠起来，在此提交之前和之后有 4 个边缘。但它最初确实引入了 2 个新的边，需要它们右边的边来容纳这些边。

经典输出已被简化：

graph：可以简化的图形输出示例

^{签字人： James Coglan}

此提交之后的提交引入了对图形布局的一系列改进，整理了一些边缘情况，即：

• 合并其第一个父级与左侧的现有列融合
• 合并其最后一个父级与其右侧的直接邻居融合
• 折叠到提交线上方和下方左侧的边缘

这个测试案例举例说明了这些案例，并提供了一个激励性的例子，说明我打算澄清的那种历史。

合并 E 的第一个父级与 H 的父级相同，因此这些边融合在一起。

* H
|
| *-.   E
| |\ \
|/ / /
|
* B

我们可以“倾斜”此合并的显示，以便它不会引入立即折叠的其他列：

* H
|
| *   E
|/|\
|
* B

E 的最后一个父节点是 D，与 F 的父节点相同，后者是合并右侧的边。

* F
|
 \
. \   E
 \ \
 / /
| /
|/
* D

通向 D 的两条边可以更快地融合：与其在合并周围扩展 F 边然后让边塌陷，F 边可以与合并后线中的 E 边融合：

* F
|
 \
. | E
 \|
 /
|
* D

如果这与上面的“倾斜”效果相结合，我们将获得这些边的更清晰的图形显示：

* F
|
| E
|
|
* D

最后，从 C 到 A 的边在通过 B 的提交线时出现锯齿状：

| * | C
| |/
* | B
|/
* A

这可以平滑，以便这样的边缘更容易阅读：

| * | C
| |/
* / B
|/
* A

由于最近更新了日志图渲染代码，绘制某些合并开始在不再成立的条件下触发断言，这已在 Git 2.25（2020 年第一季度）中得到纠正。

请参阅Derrick Stolee ( ) 的commit a1087c9和commit 0d251c3 (07 Jan 2020 )。^{（由Junio C Hamano合并-- --在commit 1f5f3ff，2020 年 1 月 8 日）}derrickstolee
gitster

graph: 删除 assert() 以合并两个折叠的父节点

^{帮助者：Jeff King
报道者：Bradley Smith
签字人：Derrick Stolee}

当“ git log --graph”显示具有两条折叠线的合并提交时，例如：

| | | | *
| |_|_|/|
|/| | |/
| | |/|
| |/| |
| * | |
* | | |

我们触发一个 assert()：

graph.c:1228: graph_output_collapsing_line: Assertion
              `graph->mapping[i - 3] == target' failed.

断言是由eaf158f8引入的（“graph API: Use horizo​​ntal lines for more compact graphs”, 2009-04-21, Git v1.6.4-rc0 -- merge），它已经很老了。
这个断言试图说明当我们用一个斜线完成一条水平线时，那是因为我们已经达到了我们的目标。

实际上是_second_ 折叠线命中了这个断言。
我们在此代码路径中的原因是因为我们正在折叠第一行，在这种情况下，由于水平线已完成，我们正在击中目标。
但是，第二条线不能是水平线，因此它会在没有水平线的情况下崩溃。在这种情况下，断言我们已经达到目标是不合适的，因为在达到目标之前我们需要继续另一列。
在这里删除断言是安全的。

0f0f389f12 中的新行为（“ graph: tidy up display of left-skewed merges”, 2019-10-15, Git v2.25.0-rc0 -- merge在第 #2 批中列出）导致了使此断言失败成为可能的行为更改。
除了使断言成为可能之外，它还改变了多条边折叠的方式。

在一个更大的例子中，当前代码将输出如下折叠：

| | | | | | *
| |_|_|_|_|/|\
|/| | | | |/ /
| | | | |/| /
| | | |/| |/
| | |/| |/|
| |/| |/| |
| | |/| | |
| | * | | |

但是，预期的折叠应该允许多条水平线，如下所示：

| | | | | | *
| |_|_|_|_|/|\
|/| | | | |/ /
| | |_|_|/| /
| |/| | | |/
| | | |_|/|
| | |/| | |
| | * | | |

此更改不会更正此行为，但会在以后的更新中注明。

git log --graph在最近的更新中，导致合并提交的祖先线的“ ”渲染不是最佳的，浪费了一点垂直空间，这已在 Git 2.26（2020 年第一季度）中得到纠正。

见提交 c958d3b，提交 8588932（2020 年 1 月 8 日）由Derrick Stolee ( derrickstolee)。
^{（由Junio C gitsterHamano合并-- --在d52adee 提交中，2020 年 1 月 30 日）}

graph：修复多条边的折叠

^{签字人：德里克·斯托利}

此修复解决了之前test_expect_failure在t4215-log-skewed-merges.sh.

问题在于else更新内部映射时的“ ”条件graph_output_collapsing_line()。
在0f0f389f (" graph: tidy up display of left-skewed merges", 2019-10-15, Git v2.25.0-rc0 --合并在批处理#2 中列出)，左偏合并的输出被更改为允许立即第一个父级中的水平边缘，输出 bygraph_output_post_merge_line()而不是 by graph_output_collapsing_line()。
这将第一行行为浓缩如下：

在0f0f389f之前：

| | | | | | *-.
| | | | | | |\ \
| |_|_|_|_|/ | |
|/| | | | | / /

在0f0f389f之后：

| | | | | | *
| |_|_|_|_|/|\
|/| | | | |/ /
| | | | |/| /

然而，当第二个和第三个父边在后面的步骤中折叠时，出现了一个非常微妙的问题。第二个父边现在紧邻垂直边。这意味着条件

} else if (graph->mapping[i - 1] < 0) {

ingraph_output_collapsing_line()评估为 false。此条件的块是我们使用水平边缘标记将目标列与当前位置连接起来的唯一地方。

在这种情况下，最后的“ else”块运行，边缘被标记为水平，但没有回填目标和当前边缘之间的空白列。
由于第二条父边被标记为水平，因此第三条父边不会被标记为水平。
这会导致输出继续如下：

在此更改之前：

| | | | | | *
| |_|_|_|_|/|\
|/| | | | |/ /
| | | | |/| /
| | | |/| |/
| | |/| |/|
| |/| |/| |
| | |/| | |

通过添加“填充”目标列和当前列之间的水平边缘的逻辑，我们能够解决这个问题。

此更改后：

| | | | | | *
| |_|_|_|_|/|\
|/| | | | |/ /
| | |_|_|/| /
| |/| | | |/
| | | |_|/|
| | |/| | |

此输出正确匹配0f0f389f之前的边缘行为和来自0f0f389f的合并提交渲染的预期混合。