如何找到一个分支的起始提交？

Question

来自 Loeliger 的《使用 Git 进行版本控制，第二版》

Because the original commit from which a branch was started is not explicitly identified, that commit (or its equivalent) can be found algorithmically using the name of the original branch from which the new branch forked:

git merge-base original-branch new-branch

• 在存储库的图形表示中，分支是提交路径吗？

• 如果查看存储库的图形，其中分支名称指向每个分支的最新提交，但没有显示每个分支的起始提交，如何找到每个分支的起始提交？

- Tim

Answer 1

如果查看一个存储库的图形，其中分支名称指向一些提交作为分支的末端，那么如何找到每个分支的起始提交？

git log --graph --decorate

// To get the same display as in the image below add the --oneline as well
git log --graph --decorate --oneline

- CodeWizard

---

我相信你附上的截图实际上是 git log --oneline --graph --decorate。 - Zloj

谢谢。 (1) 你有输出中使用的图例描述吗？我特别不清楚不同颜色的目的是什么。如何确定每个分支的起始和结束提交？(2) 在前两个合并中，为什么没有合并分支的分支名称？(3) 我的问题更多地是关于在给定一个指向分支末端的分支名称的存储库的图形表示中找到每个分支的起始提交。我假设图形不显示起始提交。 - Tim

您可以使用颜色或编写自己的脚本来设置任何您想要的颜色。git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative 这是一个示例，演示如何更改颜色并编写自定义日志记录器输出。 - CodeWizard

谢谢。但是我的三个问题还没有解决。对于第三个问题，我想补充一下，你的命令很有帮助（这也是为什么我点赞的原因），尽管我不清楚如何阅读它的输出，我想知道如何在没有输出告诉你起始提交的情况下自己找到答案。 - Tim

黄色表示分支所指向的提交，如果您现在检查它，您将看到该提交。 - CodeWizard

Answer 2

在仓库的图形表示中，分支是一系列提交的路径，这种说法正确吗？或许吧。这取决于你对“分支”和“路径”的理解。（你是指图论中的“路径”吗？如果是，那么可能不太准确，因为“路径”只是指通过某些节点和边而不重复通过任何节点的任何非空步行；尽管现在我们需要知道你对“分支”的理解...）

如果查看一个存储库的图形，并且分支名称指向每个分支的末端，但没有显示每个分支的起始提交，那么如何找出每个分支的起始提交？通常情况下是无法找到的。以下是图形的一部分：

            B - C
          /       \
... o - A           F - G    <-- br
          \       /
            D - E

分支br的"开始提交"是什么？是B，还是A，或者比A更早（在...-o链中）？ D和/或E来自哪个其他分支（如果有的话）？

如果有其他名称，它们可能提供足够的线索来猜测：

            B - C
          /       \
... o - A           F - G    <-- br
          \       /
            D - E            <-- newfeature

日志信息也可能提供线索；例如，F 的日志信息可能是 merge branch newfeature into br。在这种情况下，D 可能是分支 newfeature 的“起始提交点”，而做出提交 F 的人是在分支 br 上执行了 git merge newfeature。因此，br 的起源很可能是在 A 之前。

引用日志也可能提供这些线索。

然而，除了日志信息外，这些其他线索都可能消失。一旦合并了 newfeature，我们就可以删除该名称（及其引用日志）；默认情况下，引用日志条目在 90 天后过期（或者如果它们所指向的对象从最顶端对象不可访问，则为 30 天）。

另一方面，同样的图可能通过不同的方式产生：

            B - C
          /       \
... o - A           F - G    <-- br
          \       /
            D - E            <-- origin/br

origin/br 的起始点可能与 br 的起始点相同，合并 F 发生在某人执行 git merge（或许是作为 git pull 的一部分）以将他/她的工作与别人的工作结合起来时。两个用户都在自己的 br 分支上工作，在共享某些仓库或存储库（或许是一个集中式服务器）。

---

当你问自己“分支 X 上的第一个提交是什么”时，Git 鼓励你停止询问（或者问自己“我为什么要关心它？”）。

- torek

---

谢谢。我还没有看到你对我的第二个问题的回复。关于你对我的第一个问题的回答：（1）通过“路径”，我指的是图论中的概念。你所说的“行走”是什么意思？你区分路径和行走吗？（2）通过“分支”，我指的是Git中的概念。老实说，我还没有找到一个清晰或严谨的分支定义。也许你可以分享一下你找到的定义？ - Tim

对于（1），我再次阅读了您关于“walk”的定义。您的意思是一个分支可以通过提交进行双向回溯吗？ - Tim

嗯，关于（1），抱歉，我在说“行走”时回到了一般图形（具有无向边，甚至允许多重图）的范畴，我使用“行走”这个词是为了瞄准“路径”的通常图论含义。由于git的提交图是一个DAG，你不能通过跟随弧线返回到一个节点，所以这里没有问题。对于（2），我也找不到任何适当的正式定义。对于（3），我知道有些人确实关心，但git并没有真正让你找出来，所以我很好奇你打算解决什么问题。还有（评论空间不足）... - torek

对于第四项，是的，分支名称（引用）会一直存在，直到您将它们删除，但是您可以删除它们，人们确实会删除它们，并且在从其他存储库获取时，您可能无法获取所有名称（例如，通常不会带上任何refs/remotes/名称），即使您确实获取了所有可达对象。 - torek

顺便说一下，在提交DAG中，“分支（branch）”的最有用定义可能是“从给定提交可达的所有内容”，有时会通过“......在合并情况下通过第一个父项修改”。但是，这个定义意味着每个分支的“开始”通常是根提交（它绝对是一个根提交；可能有多个根）。这就是为什么我认为Git让寻找“起点”变得有点无用 - 我们需要寻找其他东西（通常是LCAs）。 - torek