一般来说，这是不可能的。在分支历史记录中，一个命名分支被分支之前的分支合并和两个命名分支的中间分支看起来是一样的。

在git中，分支只是历史记录部分提示的当前名称。他们并没有很强的认同感。

这通常不是一个大问题，因为两个提交的merge-base(参见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"

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

它适用于这里提到的所有存储库，我甚至还处理了邮件列表中产生的一些棘手的存储库。我还为此写了测试。

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
}

目的:这个答案测试了在这个线程中给出的各种答案。

测试库

-- 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

正如查尔斯·贝利指出的那样，这种解决方案非常脆弱。

如果你将branch_A合并为master，然后将master合并为branch_A，而不干预提交，那么lindes的解决方案只给你最近的第一次分歧。

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

这实际上都归结为gits缺乏hg所谓的命名分支。博主jhw在他的文章《为什么我更喜欢Mercurial而不是Git》和他的后续文章《More On Mercurial vs. Git (with Graphs!)》中称这些为谱系vs.家族。我建议人们阅读它们，看看为什么一些mercurial转换错过了在git中没有命名分支。

不正确的解决方案

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

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

由Greg Hewgill提供的解返回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向我展示了一种更紧凑的编写示例存储库脚本的方法。

我似乎得到了一些快乐

git rev-list branch...master

你得到的最后一行是分支上的第一个提交，所以接下来的问题是获取它的父节点。所以

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

似乎为我工作，不需要差异等(这是有帮助的，因为我们没有那个版本的差异)

更正:如果你在主分支上，这是行不通的，但我在一个脚本中这样做，所以这不是一个问题

问题似乎是在一边的两个分支之间找到最近的单次提交切割，在另一边找到最早的共同祖先(可能是回购的初始提交)。这符合我对“分支”点的直觉。

记住，使用普通的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的解决方案可能在大多数时候都非常有效。然而，它比我的慢，因为必须遍历整个回购历史…两次。: -)

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

^main branch_A给出的是J—I—H—G -1得到G git rev-parse G^给你它的第一个父:A或branch_A_tag

使用测试脚本:

mkdir branchOrigin
cd branchOrigin
git init
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 (Q2 2022)中，“Git log”(man)和朋友们学习了一个选项——exclude-first-parent-only只沿着第一个父链向下传播UNINTERESTING位，就像——first-parent选项只显示在第一个父链上缺乏UNINTERESTING位的提交一样。

参见Jerry Zhang (Jerry -skydio)提交的9d505b7 (11 Jan 2022)。 (由Junio C Hamano—gitster—在commit 708cbef中合并，2022年2月17日)

Git-rev-list: add——exclude-first-parent-only标志 署名:Jerry Zhang

It is useful to know when a branch first diverged in history from some integration branch in order to be able to enumerate the user's local changes. However, these local changes can include arbitrary merges, so it is necessary to ignore this merge structure when finding the divergence point. In order to do this, teach the "rev-list" family to accept "--exclude-first-parent-only", which restricts the traversal of excluded commits to only follow first parent links. -A-----E-F-G--main \ / / B-C-D--topic In this example, the goal is to return the set {B, C, D} which represents a topic branch that has been merged into main branch. git rev-list topic ^main(man) will end up returning no commits since excluding main will end up traversing the commits on topic as well. git rev-list --exclude-first-parent-only topic ^main(man) however will return {B, C, D} as desired. Add docs for the new flag, and clarify the doc for --first-parent to indicate that it applies to traversing the set of included commits only.

Rev-list-options现在包括在它的手册页:

——“首席家长 当找到要包含的提交时，只遵循第一个 父节点在看到合并提交时提交。 这个选项 能给一个更好的概述时，查看的演变 一个特定的主题分支，因为合并到一个主题中 分支倾向于只调整到更新的上游 时不时地，这个选项可以让你忽略 个人的承诺被带入你的历史 一个合并。

Rev-list-options现在包括在它的手册页:

——exclude-first-parent-only 当发现提交排除(使用'{插入符号}')时，只跟随 第一个父节点在看到合并提交时提交。 这可用于查找主题分支中的更改集 从它与远分支的分歧点开始 任意的合并可以是有效的主题分支更改。