用 Git 寻找分支点？

Question

我有一个包含 master 和 A 分支的存储库，以及两者之间的大量合并活动。当基于master创建分支A时，如何在我的存储库中找到提交？

我的存储库基本上如下所示：

-- X -- A -- B -- C -- D -- F  (master) 
          \     /   \     /
           \   /     \   /
             G -- H -- I -- J  (branch A)

我正在寻找修订版 A，这不是 git merge-base (--all) 找到的。

Answer 1

[注意：对使用历史默认名称“master”表示歉意 - 我会将其更改为“main”，但这会破坏示例存储库的 shas。]

我正在寻找同样的事情，我发现了这个问题。谢谢你的提问！

然而，我发现我在这里看到的答案似乎并没有完全给出您要求的答案（或者我正在寻找的答案）——它们似乎给出了G 提交，而不是 A 提交。

所以，我创建了以下树（按时间顺序分配的字母），这样我就可以测试一下：

A - B - D - F - G   <- "master" branch (at G)
     \   \     /
      C - E --'     <- "topic" branch (still at E)

这看起来与你的有点不同，因为我想确保我得到了（指的是这个图，而不是你的） B，但不是 A（也不是 D 或 E）。以下是附加到 SHA 前缀和提交消息的字母（我的存储库可以从

G: a9546a2 merge from topic back to master
F: e7c863d commit on master after master was merged to topic
E: 648ca35 merging master onto topic
D: 37ad159 post-branch commit on master
C: 132ee2a first commit on topic branch
B: 6aafd7f second commit on master before branching
A: 4112403 initial commit on master

那么，目标：找到 B。经过一番修改后，我发现了以下三种方法：

---

1. 视觉上，使用 gitk：

您应该视觉上看到这样的树（从 master 处查看）：

或此处（从主题查看）：

在这两种情况下，我都选择了图中的 B 提交。单击它后，其完整 SHA 将显示在图表下方的文本输入字段中。

---

2. 视觉上，但从终端：

git log --graph --oneline --all

（编辑/旁注：添加 --decorate 也可以很有趣；它添加了分支名称、标签等的指示。没有将其添加到上面的命令行，因为下面的输出没有反映其用途。）

显示（假设 git config - -global color.ui auto):

或者，在直接文本中：

*   a9546a2 merge from topic back to master
|\  
| *   648ca35 merging master onto topic
| |\  
| * | 132ee2a first commit on topic branch
* | | e7c863d commit on master after master was merged to topic
| |/  
|/|   
* | 37ad159 post-branch commit on master
|/  
* 6aafd7f second commit on master before branching
* 4112403 initial commit on master

无论哪种情况，我们都将 6aafd7f 提交视为最低公共点，即我的图中的 B 或您的图中的 A 。

---

3. 使用 shell magic：

您没有在问题中指定您是否需要类似上面的内容，或者只需要一个命令即可获得一个修订版，而不是其他任何内容。好吧，这是后者：

diff -u <(git rev-list --first-parent topic) \
             <(git rev-list --first-parent master) | \
     sed -ne 's/^ //p' | head -1
6aafd7ff98017c816033df18395c5c1e7829960d

您也可以将其作为 放入 ~/.gitconfig 中（注意：尾随破折号很重要；谢谢 Brian 引起了人们的注意）：

[alias]
    oldest-ancestor = !zsh -c 'diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne \"s/^ //p\" | head -1' -

这可以通过以下（用引号引起来的）命令行来完成：

git config --global alias.oldest-ancestor '!zsh -c '\''diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne "s/^ //p" | head -1'\'' -'

注意：zsh 也可以很容易地bash，但 sh 将无法工作——普通 <() 语法不存在 <代码>sh。 （再次感谢@conny，让我在本页另一个答案的评论中意识到这一点！）

然后可以从 shell 中将其用作：

git oldest-ancestor master branch_A

注意：上述的替代版本：

感谢 liori for 指出在比较相同的分支时，上述内容可能会失败，并提出一种替代的 diff 形式，从混合中删除 sed 形式，并使之“更安全”（即它返回结果（即最近的提交），即使您将 master 与 master 进行比较）：

作为 .git-config 行：

[alias]
    oldest-ancestor = !zsh -c 'diff --old-line-format='' --new-line-format='' <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | head -1' -

来自 shell：

git config --global alias.oldest-ancestor '!zsh -c '\''diff --old-line-format='' --new-line-format='' <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | head -1'\'' -'

所以，在我的测试树中（有一段时间不可用，抱歉；它回来了），现在适用于 master 和 topic（分别给出提交 G 和 B）。再次感谢 liori 提供的替代形式。

---

这就是我[和 liori] 的想法。这似乎对我有用。它还允许使用额外的几个别名，这些别名可能会很方便：

git config --global alias.branchdiff '!sh -c "git diff `git oldest-ancestor`.."'
git config --global alias.branchlog '!sh -c "git log `git oldest-ancestor`.."'

Happy git-ing！

Answer 2

您可能正在寻找 git merge-base：

git merge-base 查找两个提交之间的最佳公共祖先，以在三向合并中使用。如果另一个共同祖先是前者的祖先，则一个共同祖先优于。没有任何更好共同祖先的共同祖先是最佳共同祖先，即合并基础。请注意，一对提交可以有多个合并基础。

Answer 3

我已经使用 git rev-list 来完成此类事情。例如，（注意3点）

$ git rev-list --boundary branch-a...master | grep "^-" | cut -c2-

将吐出分支点。现在，它并不完美；因为您已将 master 合并到分支 A 几次，所以会分裂出几个可能的分支点（基本上是原始分支点，然后是您将 master 合并到分支 A 的每个点） ）。然而，它至少应该缩小可能性。

我已将该命令添加到 ~/.gitconfig 中的别名中：

[alias]
    diverges = !sh -c 'git rev-list --boundary $1...$2 | grep "^-" | cut -c2-'

这样我就可以将其称为：

$ git diverges branch-a master

Answer 4

如果您喜欢简洁的命令，

git rev-list $(git rev-list --first-parent ^branch_name master | tail -n1)^^! 

这里有一个解释。

以下命令为您提供了创建branch_name后发生的master中所有提交的列表，

git rev-list --first-parent ^branch_name master 

因为您只关心这些提交中最早的提交，所以您需要输出的最后一行：

git rev-list ^branch_name --first-parent master | tail -n1

最早提交的父级，它不是“branch_name”的祖先根据定义，在“branch_name”中，并且在“master”中，因为它是“master”中某些内容的祖先。因此，您已经获得了两个分支中最早的提交。

该命令

git rev-list commit^^!

只是显示父提交引用的一种方法。你可以使用

git log -1 commit^

或其他什么。

PS：我不同意祖先顺序无关的论点。这取决于你想要什么。例如，在这种情况下，

_C1___C2_______ master
  \    \_XXXXX_ branch A (the Xs denote arbitrary cross-overs between master and A)
   \_____/ branch B

输出 C2 作为“分支”提交是非常有意义的。这是开发人员从“master”分支出来的时候。当他分支时，分支“B”甚至没有合并到他的分支中！这就是这篇文章中给出的解决方案。

如果您想要的是最后一次提交 C，以便从原点到分支“A”上的最后一次提交的所有路径都经过 C，那么您希望忽略祖先顺序。这纯粹是拓扑结构，让您了解何时同时运行两个版本的代码。这时您将采用基于合并的方法，在我的示例中它将返回 C1。

Answer 5

目的：此答案测试此线程中提供的各种答案。

测试存储库

-- X -- A -- B -- C -- D -- F  (master) 
          \     /   \     /
           \   /     \   /
             G -- H -- I -- J  (branch A)

$ git --no-pager log --graph --oneline --all --decorate
* b80b645 (HEAD, branch_A) J - Work in branch_A branch
| *   3bd4054 (master) F - Merge branch_A into branch master
| |\  
| |/  
|/|   
* |   a06711b I - Merge master into branch_A
|\ \  
* | | bcad6a3 H - Work in branch_A
| | * b46632a D - Work in branch master
| |/  
| *   413851d C - Merge branch_A into branch master
| |\  
| |/  
|/|   
* | 6e343aa G - Work in branch_A
| * 89655bb B - Work in branch master
|/  
* 74c6405 (tag: branch_A_tag) A - Work in branch master
* 7a1c939 X - Work in branch master

正确的解决方案

唯一有效的解决方案是 lindes 提供的解决方案正确返回 A：

$ diff -u <(git rev-list --first-parent branch_A) \
          <(git rev-list --first-parent master) | \
      sed -ne 's/^ //p' | head -1
74c6405d17e319bd0c07c690ed876d65d89618d5

正如 Charles Bailey 指出的那样，这个解决方案非常脆弱。

如果您将 branch_A 合并到 master 中，然后将 master 合并到 branch_A 中而不干预提交，那么 lindes 的解决方案只会为您提供最近的第一次背离。

这意味着对于我的工作流程，我认为我将不得不坚持标记长时间运行的分支的分支点，因为我不能保证以后可以可靠地找到它们。

这实际上都归结为 git 缺乏 hg 所谓的命名分支。博主 jhw 在他的文章 血统与家族称为>为什么我比 Git 更喜欢 Mercurial 及其后续文章 有关 Mercurial 与 Git 的更多信息 (与图表！）。我建议人们阅读它们，看看为什么一些善变的皈依者错过了 git 中没有命名分支。

不正确的解决方案

mpadi 提供的解决方案返回两个答案，I 和 C:

$ git rev-list --boundary branch_A...master | grep ^- | cut -c2-
a06711b55cf7275e8c3c843748daaa0aa75aef54
413851dfecab2718a3692a4bba13b50b81e36afc

Greg Hewgill 提供的解决方案 return I

$ git merge-base master branch_A
a06711b55cf7275e8c3c843748daaa0aa75aef54
$ git merge-base --all master branch_A
a06711b55cf7275e8c3c843748daaa0aa75aef54

Karl 返回 X：

$ diff -u <(git log --pretty=oneline branch_A) \
          <(git log --pretty=oneline master) | \
       tail -1 | cut -c 2-42
7a1c939ec325515acfccb79040b2e4e1c3e7bbe5

测试存储库复制

要创建测试存储库：

mkdir $1
cd $1
git init
git commit --allow-empty -m "X - Work in branch master"
git commit --allow-empty -m "A - Work in branch master"
git branch branch_A
git tag branch_A_tag     -m "Tag branch point of branch_A"
git commit --allow-empty -m "B - Work in branch master"
git checkout branch_A
git commit --allow-empty -m "G - Work in branch_A"
git checkout master
git merge branch_A       -m "C - Merge branch_A into branch master"
git checkout branch_A
git commit --allow-empty -m "H - Work in branch_A"
git merge master         -m "I - Merge master into branch_A"
git checkout master
git commit --allow-empty -m "D - Work in branch master"
git merge branch_A       -m "F - Merge branch_A into branch master"
git checkout branch_A
git commit --allow-empty -m "J - Work in branch_A branch"

我唯一的添加是使其明确的标记关于我们创建分支的点以及我们希望找到的提交。

我怀疑 git 版本对此有何影响，但是：

$ git --version
git version 1.7.1

感谢 Charles Bailey 向我展示了一种更紧凑的脚本编写方式示例存储库。

Answer 6

一般来说，这是不可能的。在分支历史记录中，在命名分支分支之前进行分支合并，并且两个命名分支的中间分支看起来相同。

在 git 中，分支只是历史记录部分的当前名称。他们确实没有很强的身份。

这通常不是一个大问题，因为两个提交的合并基础（参见 Greg Hewgill 的答案）通常更有用，给出两个分支共享的最新提交。

在分支历史记录中的某个时刻已完全集成分支的情况下，依赖于提交父级顺序的解决方案显然不起作用。

git commit --allow-empty -m root # actual branch commit
git checkout -b branch_A
git commit --allow-empty -m  "branch_A commit"
git checkout master
git commit --allow-empty -m "More work on master"
git merge -m "Merge branch_A into master" branch_A # identified as branch point
git checkout branch_A
git merge --ff-only master
git commit --allow-empty -m "More work on branch_A"
git checkout master
git commit --allow-empty -m "More work on master"

如果在父级相反的情况下进行了集成合并（例如，使用临时分支来执行到主分支的测试合并，然后快进到功能分支以进一步构建），则该技术也会失败。

git commit --allow-empty -m root # actual branch point
git checkout -b branch_A
git commit --allow-empty -m  "branch_A commit"
git checkout master
git commit --allow-empty -m "More work on master"
git merge -m "Merge branch_A into master" branch_A # identified as branch point
git checkout branch_A
git commit --allow-empty -m "More work on branch_A"

git checkout -b tmp-branch master
git merge -m "Merge branch_A into tmp-branch (master copy)" branch_A
git checkout branch_A
git merge --ff-only tmp-branch
git branch -d tmp-branch

git checkout master
git commit --allow-empty -m "More work on master"

Answer 7

Git 2.36 提出了一个更简单的命令：

(branch_A_tag)
     |
--X--A--B--C--D--F  (master) 
      \   / \   /
       \ /   \ /
        G--H--I--J  (branch A)

vonc@vclp MINGW64 ~/git/tests/branchOrigin (branch_A)
git log -1 --decorate --oneline \
  $(git rev-parse \
     $(git rev-list --exclude-first-parent-only ^main branch_A| tail -1)^ \
   )
 80e8436 (tag: branch_A_tag) A - Work in branch main

with:

• git rev-list --exclude-first-parent-only ^mainbranch_A 为您提供 J -- I -- H -- G code>
• tail -1 为您提供 G
• git rev-parse G^ 为您提供其第一个父级：A 或branch_A_tag

（PowerShell 等效项，来自 < a href="https://stackoverflow.com/users/5887576/kumarchandresh">kumarchandresh 的 评论：
git log -1 --decorate --oneline $(git rev-parse "$(git rev-list --exclude-first-parent-only ^mainbranch_A_tag | select -last 1)^")）

使用测试脚本：

mkdir branchOrigin
cd branchOrigin
git init -b main
git commit --allow-empty -m "X - Work in branch main"
git commit --allow-empty -m "A - Work in branch main"
git tag branch_A_tag     -m "Tag branch point of branch_A"
git commit --allow-empty -m "B - Work in branch main"
git switch -c branch_A branch_A_tag
git commit --allow-empty -m "G - Work in branch_A"
git switch main
git merge branch_A       -m "C - Merge branch_A into branch main"
git switch branch_A
git commit --allow-empty -m "H - Work in branch_A"
git merge main         -m "I - Merge main into branch_A"
git switch main
git commit --allow-empty -m "D - Work in branch main"
git merge branch_A       -m "F - Merge branch_A into branch main"
git switch branch_A
git commit --allow-empty -m "J - Work in branch_A branch"

这给你：

vonc@vclp MINGW64 ~/git/tests/branchOrigin (branch_A)
$ git log --oneline --decorate --graph --branches --all
* a55a87e (HEAD -> branch_A) J - Work in branch_A branch
| *   3769cc8 (main) F - Merge branch_A into branch main
| |\
| |/
|/|
* |   1b29fa5 I - Merge main into branch_A
|\ \
* | | e7accbd H - Work in branch_A
| | * 87a62f4 D - Work in branch main
| |/
| *   7bc79c5 C - Merge branch_A into branch main
| |\
| |/
|/|
* | 0f28c9f G - Work in branch_A
| * e897627 B - Work in branch main
|/
* 80e8436 (tag: branch_A_tag) A - Work in branch main
* 5cad19b X - Work in branch main

这是：

(branch_A_tag)
     |
--X--A--B--C--D--F  (master) 
      \   / \   /
       \ /   \ /
        G--H--I--J  (branch A)

---

使用 Git 2.36（2022 年第二季度），“git 日志"^(man) 和朋友们学到了一个选项 --exclude-first-parent-only 只沿着第一个父链向下传播无趣的位，只是like --first-parent 选项显示仅沿着第一个父链缺少 UNINTERESTING 位的提交。

请参阅 提交 9d505b7（2022 年 1 月 11 日），作者：张杰瑞 (jerry-skydio)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 708cbef，2022 年 2 月 17 日）}

git-rev-list：添加 - -排除第一父级标志

^{签字人：张杰}

为了能够枚举用户的本地更改，了解分支在历史中首次与某些集成分支分离的时间非常有用。
然而，这些局部变化可以包括任意合并，因此在寻找分歧点时有必要忽略这种合并结构。

为了做到这一点，请教导“rev-list”系列接受“--exclude-first-parent-only”，这限制遍历排除的提交仅遵循第一个父链接。

<前><代码>-A-----EFG--main
\//
BCD--主题

在此示例中，目标是返回集合 {B, C, D}，它表示已合并到 main< 中的主题分支/code> 分支。
git rev-list 主题 ^main(man)最终将不会返回任何提交，因为排除 main 最终也会遍历 topic 上的提交。
git rev-list --exclude -first-parent-only 主题 ^main(man) 但是会根据需要返回 {B, C, D} .

为新标志添加文档，并澄清 --first-parent 的文档，以指示它仅适用于遍历包含的提交集。

rev-list-options 现在包含在其 手册页：

--first-parent

当查找要包含的提交时，仅遵循第一个
看到合并提交后父提交。

这个选项
在查看演变过程时可以提供更好的概览
特定主题分支，因为合并到主题中
分支往往只是为了适应更新的上游
有时，此选项允许您忽略
个人通过这样的方式将承诺带入你的历史
合并。

rev-list-options 现在包含在其 手册页：

--仅排除第一父级

当查找要排除的提交（带有“{caret}”）时，仅遵循
看到合并提交后的第一个父提交。

这可用于查找主题分支中的更改集
从它与远程分支分叉的点开始，给定
任意合并都可以是有效的主题分支更改。

---

正如 anarcat 在 注释，如果您的分支不是源自master，而是源自< code>main，或 prod，或...任何其他分支，您可以使用：

git for-each-ref --merged="$local_ref" --no-contains="$local_ref" \
    --format="%(refname:strip=-1)" --sort='-*authordate' 参考文献/标题

---

philb 也在 评论 --boundary 选项（输出排除的边界提交。边界提交以 - 为前缀）：

git rev-list --exclude-first-parent-only --boundary ^main 分支_A |尾部-1 

直接获取A，无需额外的git rev-parse G^

Answer 8

怎么样

git log --pretty=oneline master > 1
git log --pretty=oneline branch_A > 2

git rev-parse `diff 1 2 | tail -1 | cut -c 3-42`^

Answer 9

一种更容易在 git log --graph 中查看分支点的简单方法是使用选项 --first-parent。

例如，从 repo 获取https://stackoverflow.com/a/4991675/3217306">接受的答案：

$ git log --all --oneline --decorate --graph

*   a9546a2 (HEAD -> master, origin/master, origin/HEAD) merge from topic back to master
|\  
| *   648ca35 (origin/topic) merging master onto topic
| |\  
| * | 132ee2a first commit on topic branch
* | | e7c863d commit on master after master was merged to topic
| |/  
|/|   
* | 37ad159 post-branch commit on master
|/  
* 6aafd7f second commit on master before branching
* 4112403 initial commit on master

现在添加--first-parent：

$ git log --all --oneline --decorate --graph --first-parent

* a9546a2 (HEAD -> master, origin/master, origin/HEAD) merge from topic back to master
| * 648ca35 (origin/topic) merging master onto topic
| * 132ee2a first commit on topic branch
* | e7c863d commit on master after master was merged to topic
* | 37ad159 post-branch commit on master
|/  
* 6aafd7f second commit on master before branching
* 4112403 initial commit on master

这使得它更容易！

请注意，如果存储库有很多分支，您将需要指定要比较的 2 个分支，而不是使用 --all：

$ git log --decorate --oneline --graph --first-parent master origin/topic

Answer 10

当然我错过了一些东西，但是在我看来，上述所有问题都是因为我们总是试图找到历史记录中的分支点而引起的，并且由于可用的合并组合而导致了各种问题。

相反，我采用了不同的方法，基于两个分支共享大量历史记录的事实，分支之前的所有历史记录都是 100% 相同的，所以我的建议不是回去，而是继续前进（从第一个分支开始） commit），寻找两个分支中的第一个差异。简而言之，分支点将是找到的第一个差异的父点。

在实践中：

#!/bin/bash
diff <( git rev-list "${1:-master}" --reverse --topo-order ) \
     <( git rev-list "${2:-HEAD}" --reverse --topo-order) \
--unified=1 | sed -ne 's/^ //p' | head -1

它解决了我所有常见的情况。当然，还有一些边界没有被覆盖，但是......再见:-)

Answer 11

经过大量研究和讨论，很明显没有一种灵丹妙药可以在所有情况下发挥作用，至少在当前版本的 Git 中是这样。

这就是为什么我编写了几个补丁来添加 tail 分支的概念。每次创建分支时，也会创建一个指向原始点的指针，即 tail ref。每次分支变基时，该引用都会更新。

要找出devel分支的分支点，你所要做的就是使用devel@{tail}，就是这样。

https://github.com/felipec/git/commits/fc/tail

Answer 12

我最近也需要解决这个问题，并最终为此编写了一个 Ruby 脚本： https: //github.com/vaneyckt/git-find-branching-point

Answer 13

我似乎对

git rev-list branch...master

你得到的最后一行是分支上的第一个提交感到高兴，所以这是获取其父级的问题。所以

git rev-list -1 `git rev-list branch...master | tail -1`^

似乎对我有用并且不需要差异等（这很有帮助，因为我们没有该版本的差异）

更正：如果您在主分支上，这不起作用，但我正在做这在脚本中，所以这不是一个问题

Answer 14

有时这实际上是不可能的（除了一些例外，您可能幸运地拥有额外的数据）并且这里的解决方案不起作用。

Git 不保留引用历史记录（包括分支）。它只存储每个分支（头部）的当前位置。这意味着随着时间的推移，您可能会丢失 git 中的一些分支历史记录。例如，每当您进行分支时，就会立即丢失哪个分支是原始分支。分支所做的只是：

git checkout branch1    # refs/branch1 -> commit1
git checkout -b branch2 # branch2 -> commit1

您可能假设第一个提交的是该分支。情况往往如此，但并非总是如此。在上述操作之后，没有什么可以阻止您首先提交到任一分支。此外，不保证 git 时间戳的可靠性。直到你同时致力于两者，它们才真正成为结构上的分支。

虽然在图中我们倾向于在概念上对提交进行编号，但当提交树分支时，git 没有真正稳定的顺序概念。在这种情况下，您可以假设数字（指示顺序）由时间戳确定（当您将所有时间戳设置为相同时，看看 git UI 如何处理事情可能会很有趣）。

这是人们在概念上所期望的：

After branch:
       C1 (B1)
      /
    -
      \
       C1 (B2)
After first commit:
       C1 (B1)
      /
    - 
      \
       C1 - C2 (B2)

这就是你实际得到的：

After branch:
    - C1 (B1) (B2)
After first commit (human):
    - C1 (B1)
        \
         C2 (B2)
After first commit (real):
    - C1 (B1) - C2 (B2)

你会假设 B1 是原始分支，但它实际上可能只是一个死分支（有人签出 -b 但从未提交给它）。直到你同时提交这两个内容，你才能在 git 中获得合法的分支结构：

Either:
      / - C2 (B1)
    -- C1
      \ - C3 (B2)
Or:
      / - C3 (B1)
    -- C1
      \ - C2 (B2)

你总是知道 C1 在 C2 和 C3 之前，但你永远无法可靠地知道 C2 是在 C3 之前还是 C3 在 C2 之前（因为你可以设置时间）例如，您的工作站到任何东西）。 B1 和 B2 也具有误导性，因为你不知道哪个分支先出现。在许多情况下，您可以对其做出非常好的且通常准确的猜测。这有点像赛道。一般而言，在所有情况与汽车相同的情况下，您可以假设落后一圈的汽车开始落后一圈。我们也有非常可靠的约定，例如 master 几乎总是代表寿命最长的分支，尽管遗憾的是我见过情况并非如此。

这里给出的例子是一个历史保存的例子：

Human:
    - X - A - B - C - D - F (B1)
           \     / \     /
            G - H ----- I - J (B2)
Real:
            B ----- C - D - F (B1)
           /       / \     /
    - X - A       /   \   /
           \     /     \ /
            G - H ----- I - J (B2)

这里的 Real 也具有误导性，因为我们作为人类从左到右、从根到叶阅读它（参考）。 Git 不这样做。当我们在头脑中做 (A->B) 的地方，git 会做 (A<-B 或 B->A)。它从 ref 读取到 root。引用可以在任何地方，但往往是叶子，至少对于活跃的分支来说是这样。引用指向一个提交，并且提交仅包含对其父级的“like”，而不是其子级的“like”。当一项提交是合并提交时，它将有多个父项。第一个父级始终是合并到的原始提交。其他父项始终是合并到原始提交中的提交。

Paths:
    F->(D->(C->(B->(A->X)),(H->(G->(A->X))))),(I->(H->(G->(A->X))),(C->(B->(A->X)),(H->(G->(A->X)))))
    J->(I->(H->(G->(A->X))),(C->(B->(A->X)),(H->(G->(A->X)))))

这不是一个非常有效的表示，而是 git 可以从每个引用（B1 和 B2）获取的所有路径的表达式。

Git 的内部存储看起来更像这样（不是 A 作为父项出现两次）：

    F->D,I | D->C | C->B,H | B->A | A->X | J->I | I->H,C | H->G | G->A

如果转储原始 git 提交，您将看到零个或多个父字段。如果为零，则意味着没有父级，并且提交是根（实际上可以有多个根）。如果有，则意味着没有合并，也不是根提交。如果有多个，则意味着该提交是合并的结果，并且第一个之后的所有父级都是合并提交。

Paths simplified:
    F->(D->C),I | J->I | I->H,C | C->(B->A),H | H->(G->A) | A->X
Paths first parents only:
    F->(D->(C->(B->(A->X)))) | F->D->C->B->A->X
    J->(I->(H->(G->(A->X))) | J->I->H->G->A->X
Or:
    F->D->C | J->I | I->H | C->B->A | H->G->A | A->X
Paths first parents only simplified:
    F->D->C->B->A | J->I->->G->A | A->X
Topological:
    - X - A - B - C - D - F (B1)
           \
            G - H - I - J (B2)

当两者都击中 A 时，它们的链条将相同，在此之前它们的链条将完全不同。第一个提交和另外两个提交的共同点是共同的祖先，并且从那里它们开始分歧。术语提交、分支和引用之间可能存在一些混淆。事实上你可以合并一个提交。这就是合并真正要做的事情。 ref 只是指向提交，而分支只不过是文件夹 .git/refs/heads 中的引用，文件夹位置决定了引用是分支而不是其他内容（例如标签）。

丢失历史记录的地方是，合并将根据情况执行以下两件事之一。

考虑：

      / - B (B1)
    - A
      \ - C (B2)

在这种情况下，任一方向的合并都会创建一个新的提交，其中第一个父级作为当前签出分支指向的提交，第二个父级作为合并到当前分支的分支尖端的提交。它必须创建一个新的提交，因为两个分支自必须合并的共同祖先以来都发生了变化。

      / - B - D (B1)
    - A      /
      \ --- C (B2)

此时，D (B1) 现在具有来自两个分支（其本身和 B2）的两组更改。然而，第二个分支没有 B1 的变化。如果您将 B1 中的更改合并到 B2 中，以便它们同步，那么您可能会期望看起来像这样的东西（您可以强制 git merge 这样做，但是使用 --no-ff）：

Expected:
      / - B - D (B1)
    - A      / \
      \ --- C - E (B2)
Reality:
      / - B - D (B1) (B2)
    - A      /
      \ --- C

即使 B1 您也会得到有额外的提交。只要 B2 中不存在 B1 中没有的更改，两个分支就会合并。它执行快进，类似于变基（变基也吃掉或线性化历史记录），但与变基不同的是，因为只有一个分支具有更改集，所以它不必将一个分支的变更集应用到另一个分支的变更集之上。

From:
      / - B - D - E (B1)
    - A      /
      \ --- C (B2)
To:
      / - B - D - E (B1) (B2)
    - A      /
      \ --- C

如果你停止 B1 的工作，那么从长远来看，对于保存历史来说，一切都很好。通常只有 B1（可能是 master）会前进，因此 B2 在 B2 历史记录中的位置成功地代表了它被合并到 B1 中的点。这就是 git 希望你做的事情，从 A 分支 B，然后随着变化的累积，你可以根据需要将 A 合并到 B 中，但是当将 B 合并回 A 时，并不期望你会在 B 上工作并进一步工作。如果您在快进合并回您正在处理的分支后继续处理您的分支，那么您每次都会删除 B 之前的历史记录。每次快速提交到源代码然后提交到分支之后，您实际上都是在创建一个新分支。当您快进提交时，您最终会看到许多分支/合并，您可以在历史记录和结构中看到这些分支/合并，但无法确定该分支的名称是什么，或者看起来两个单独的分支是否实际上是同一个分支。

         0   1   2   3   4 (B1)
        /-\ /-\ /-\ /-\ /
    ----   -   -   -   -
        \-/ \-/ \-/ \-/ \
         5   6   7   8   9 (B2)

1 到 3 和 5 到 8 是结构分支，如果您跟踪 4 或 9 的历史记录，就会出现。在 git 中无法知道这些未命名和未引用的结构分支属于命名和引用分支中的哪一个作为结构的末端。你可能会从这张图中假设0到4属于B1，4到9属于B2，但除了4和9之外，无法知道哪个分支属于哪个分支，我只是以一种给出的方式绘制它对此的幻觉。 0 可能属于 B2，5 可能属于 B1。在这种情况下，每个结构分支可能属于其中的命名分支，有 16 种不同的可能性。这是假设这些结构分支都不是来自已删除的分支，或者是从主库拉取时将分支合并到自身的结果（两个存储库上的相同分支名称实际上是两个分支，单独的存储库就像分支所有分支） 。

有许多 git 策略可以解决这个问题。您可以强制 git merge 从不快进并始终创建合并分支。保存分支历史记录的一种可怕方法是根据您选择的某些约定使用标签和/或分支（确实推荐使用标签）。我真的不建议在您要合并的分支中进行虚拟的空提交。一个非常常见的约定是，除非您想真正关闭分支，否则不要合并到集成分支中。人们应该尝试遵守这种做法，否则你就在围绕建立分支机构的问题进行工作。然而，在现实世界中，理想并不总是实际的，这意味着做正确的事情并不适用于所有情况。如果您在一个分支上所做的事情是孤立的，那么您可能会遇到这样的情况：当多个开发人员正在处理某件事时，他们需要快速共享他们的更改（理想情况下，您可能真的想在一个分支上工作，但并非所有情况都适合，通常您要避免两个人在一个分支机构工作）。

Answer 15

这是我之前的答案之前的答案的改进版本。它依赖于合并的提交消息来查找首次创建分支的位置。

它适用于这里提到的所有存储库，我什至解决了 产生的一些棘手的存储库在邮件列表上。我还为此编写了测试。

find_merge ()
{
    local selection extra
    test "$2" && extra=" into $2"
    git rev-list --min-parents=2 --grep="Merge branch '$1'$extra" --topo-order ${3:---all} | tail -1
}

branch_point ()
{
    local first_merge second_merge merge
    first_merge=$(find_merge $1 "" "$1 $2")
    second_merge=$(find_merge $2 $1 $first_merge)
    merge=${second_merge:-$first_merge}

    if [ "$merge" ]; then
        git merge-base $merge^1 $merge^2
    else
        git merge-base $1 $2
    fi
}

Answer 16

以下命令将显示提交 A 的 SHA1

git merge-base --fork-point A

Answer 17

这并不是问题的解决方案，但我认为值得注意的是当我有一个长期存在的分支时我使用的方法：

在创建分支的同时，我还创建了一个具有相同名称但带有 < 的标签code>-init 后缀，例如 feature-branch 和 feature-branch-init。

（这是一个很难回答的问题，这有点奇怪！）

Answer 18

似乎使用 reflog 解决了这个问题 git reflog 显示了分支的所有提交，包括分支创建。

这是来自一个在合并回 master 之前有 2 次提交的分支。

git reflog june-browser-updates
b898b15 (origin/june-browser-updates, june-browser-updates) june-browser-updates@{0}: commit: sorted cve.csv
467ae0e june-browser-updates@{1}: commit: browser updates and cve additions
d6a37fb june-browser-updates@{2}: branch: Created from HEAD

Answer 19

要查找来自分支点的提交，您可以使用它。

git log --ancestry-path master..topicbranch

Answer 20

解决方案是找到第一个分歧，然后取父分歧。使用 zsh，可以按如下方式完成此操作（编辑：与我的第一个答案相比，我添加了缺少的 --topo-order；我忘记了它在存储库上进行测试，其中所有提交都具有相同的日期（由脚本生成）：

git rev-parse "$(diff <(git rev-list --topo-order --reverse master) \
                      <(git rev-list --topo-order --reverse branch_A) | \
                 sed -n '2{s/^. //p;q}')^"

sed 选择仅出现在一个分支中的第一个提交。然后 git rev-parse "$(...)^" 输出其父级。

注意：

• 无论 branch_A 是否已与 master 合并，这都有效（在合并的情况下，branch_A 的头对应于最后一次提交在合并之前的这个分支中）。
• 在某些情况下，分支点的概念是不明确的。因此，一个人可能得不到自己真正想要的东西。这种情况也发生在 GNU MPFR 存储库（4.0 分支）中。
• diff 并不是最佳选择，因为只需要第一个差异，但这似乎是标准 Unix 实用程序的最简单解决方案。

编辑：

如果在某处进行合并，两个分支之一中合并之前的第一次提交可能不是使用 diff 看到的分歧的一部分（请注意，尽管如此，结果在某些情况下可能仍然有意义）。因此，最好查看两侧的第一个分歧，即对于 diff，第一次插入和第一次删除（如果可用）。

上述解决方案的另一个可能的问题是，在合并提交的情况下，^ 选择第一个父级，而人们希望合并被视为对称。因此，为了选择父母双方，^@ 是首选。

最后，在通过上述注释获得的可能的分支点中，选择最旧的一个：这是由 git rev-list --topo-order --reverse --no-walk ... | 完成的head -n 1 下面（请注意，由于 --reverse，不能使用 -1 或 -n 1 作为git rev-list 选项而不是指向 head -n 1 的管道）。

因此，这是一个完整的解决方案，可用作脚本，其中 master 和 HEAD 作为分支的默认值：

git rev-list --topo-order --reverse --no-walk \
  $(diff -u <(git rev-list --topo-order --reverse "${1:-master}") \
            <(git rev-list --topo-order --reverse "${2:-HEAD}") | \
      perl -e 'while (<>) { /^([-+])([^-+].*)/ and $h{$1} //= "$2^@\n";
                            last if %h > 1 }
               print values %h') | head -n 1

--topo-order描述不是很详细，但这似乎在各种复杂的示例上按预期工作。但也可能有更复杂的例子，其中分支点没有很好地定义。

Answer 21

问题似乎是在一侧的两个分支之间找到最新的单提交剪切，以及在另一侧的最早共同祖先（可能是回购协议）。这符合我对“分支”点的直觉。

考虑到这一点，使用普通的 git shell 命令来计算这一点并不容易，因为我们最强大的工具 git rev-list 不允许我们通过以下方式限制路径：达到了提交。我们拥有的最接近的是 git rev-list --boundary ，它可以为我们提供一组“阻止我们前进”的所有提交。 （注意：git rev-list --ancestry-path很有趣，但我不知道如何让它在这里有用。）

这是脚本：https://gist.github.com/abortz/d464c88923c520b79e3d。它相对简单，但由于有循环，它足够复杂以保证要点。

请注意，这里提出的大多数其他解决方案不可能在所有情况下都有效，原因很简单：git rev-list --first-parent 在线性化历史记录方面并不可靠，因为可能会与任何一个合并订购。

另一方面，git rev-list --topo-order非常有用——用于按拓扑顺序遍历提交——但是进行差异比较脆弱：有对于给定的图，有多种可能的拓扑排序，因此您依赖于排序的一定稳定性。也就是说，strongk7 的解决方案在大多数情况下可能都运行得很好。然而，由于必须遍历整个存储库的历史......两次，它比我的慢。 :-)

Answer 22

以下实现了 git 等价于 svn log --stop-on-copy 的功能，也可用于查找分支源。

方法

1. 获取所有分支的 head
2. 收集目标分支的 mergeBase 每个其他分支
3. git.log 并迭代
4. 在 mergeBase 列表中出现的第一个提交处停止

就像所有的河流都流向大海，所有的分支都流向 master 和因此我们在看似不相关的分支之间找到了合并基础。当我们从分支头返回祖先时，我们可以在第一个潜在的合并基础处停下来，因为理论上它应该是该分支的起点。

注释

• 我还没有尝试过这种兄弟分支和表兄弟分支相互合并的方法。
• 我知道一定有更好的解决方案。

详细信息：https://stackoverflow.com/a/35353202/9950

Answer 23

为什么不使用

git log master..enter_your_branch_here --oneline | tail -1

Which 为您提供分支 A 拥有但 master 没有的所有提交（.. 的功能），并使用 tail -1 返回最后一个提交输出行，这将 找到指定的第一个提交分支（分支A）。

然后，使用该提交的 SHA

git log enter_the_sha_here^1 --oneline | head -1

为您提供指定提交之前的所有提交（^1 的函数）和 head -1 返回第一行输出，这是分支 A 中最早提交的“一次提交”，也称为“分支点”。

---

作为单个可执行命令：

for COMMIT in $(git log --format=format:%H  master..HEAD | tail -1) ; do
    git log $COMMIT^1 --oneline | head -1
done

从分支 A 中运行上述命令（HEAD 的功能）

Answer 24

简单答案

将两个分支合并，现在您可以找到共同的祖先。

git merge-base master branch_a
# =>  commit_1234

# now do what you want with the commit id

git show commit_1234

# => commit commit_1234
# Author: BenKoshy
# Date:   Today
# etc

```

Answer 25

您可以检查分支 A 的引用日志，以查找它是从哪个提交创建的，以及该分支指向的提交的完整历史记录。引用日志位于 .git/logs 中。

Answer 26

您可以使用以下命令返回branch_a中最旧的提交，该提交无法从master访问：

git rev-list branch_a ^master | tail -1

也许可以通过额外的健全性检查来确保该提交的父级实际上可以从master访问...

Answer 27

我相信我已经找到了一种方法来处理这里提到的所有极端情况：

branch=branch_A
merge=$(git rev-list --min-parents=2 --grep="Merge.*$branch" --all | tail -1)
git merge-base $merge^1 $merge^2

查尔斯·贝利（Charles Bailey）说得很对，基于祖先顺序的解决方案价值有限；在一天结束时，您需要某种“此提交来自分支 X”的记录，但此类记录已经存在；默认情况下，'git merge' 将使用诸如“将分支 'branch_A' 合并到 master”之类的提交消息，这告诉您来自第二个父级的所有提交 (commit^2) 来自 'branch_A' 并合并到第一个父级父级（commit^1），即“master”。

有了这些信息，您就可以找到“branch_A”的第一次合并（这是“branch_A”真正存在的时候），并找到合并基础，这将是分支点:)

我已经尝试过以下存储库马克·布斯 (Mark Booth) 和查尔斯·贝利 (Charles Bailey) 的解决方案有效；怎么可能呢？唯一不起作用的方法是，如果您手动更改了合并的默认提交消息，则分支信息确实丢失了。

为了有用：

[alias]
    branch-point = !sh -c 'merge=$(git rev-list --min-parents=2 --grep="Merge.*$1" --all | tail -1) && git merge-base $merge^1 $merge^2'

然后你可以执行“gitbranch-pointbranch_A”。

享受 ;）