请考虑帮助我了解时间表。在一个教程中，时间线箭头指向从右到左。
也就是说，提交 7 指向提交 6，提交 6 指向提交 5，依此类推。如果提交位于数组中并且您不断将提交添加到数组的前面，则这是有道理的。然而，这不是一个（我）通常对时间线的看法。
在另一个中，时间线箭头指向从左到右（这是我通常认为的时间线。）原始提交 1 指向下一个更改的提交 (2)，等等。
正确看待 Git 时间线的方法是什么？
【问题讨论】：
从技术上讲，正确的方式是第一种方式，即指向时间向后的箭头。这是因为 git 提交的实际存储方式：每个提交都有一个指向其父级的指针。
说了这么多，你会经常看到它是双向的。使用上下文来确定正在使用哪一个。
【讨论】：
请注意，教程（至少我看过的教程）不讨论时间线，而是讨论提交图。
基本思想是除了分支中的第一个提交之外，每个提交都有一个或多个父提交。自然地，这些父/子关系形成了一个图，其中提交是它的顶点，这些关系是它的边。
教程通常使用箭头来渲染这些边缘。这些箭头指向的位置（从孩子到其父母，反之亦然）据推测取决于特定可视化的作者试图传达的内容：如果他们想传达父母/孩子的关系，则箭头应该指向父母，如果他们想突出“发展进程的方向”，箭头应该指向孩子。
请考虑尽快忘掉“时间线”这个概念——否则以后可能会咬到你。
它的问题在于它在 Git 中根本不存在。是的，git log 向您显示的内容似乎形成了一个时间线，但这具有欺骗性，因为到目前为止，您正在处理最简单的情况，即历史中提交的父/子关系线性进展沿着假想的时间线。
现在假设这个简单的例子：
如您所见，您不再有一个简单易行的时间线，因为在它的中间将是由两个“子时间线”形成的菱形:-)
当然，显示历史的 Git 工具默认情况下会很高兴地将钻石的两侧“折叠”成看起来像单个时间线但顺序不同的东西这些提交中的大部分不会反映它们的父/子关系。
因此，您越早更改 Git 存储库中的历史心智模型以采用该图形概念，您就越能更好地准备处理具有大量合并的真实存储库。
【讨论】：