你可能正在寻找git merge-base:

Git merge-base找到两个提交之间的最佳共同祖先，用于三向合并。一个共同祖先优于另一个共同祖先，如果后者是前者的祖先。没有更好的公共祖先的公共祖先是最佳公共祖先，即合并基。注意，对于一对提交可以有多个合并基。

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

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

您可以检查分支A的reflog，以找到它是从哪个提交创建的，以及该分支所指向的提交的完整历史。Reflogs在.git/logs中。

像这样的怎么样

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

我使用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

我也在寻找同样的东西，我发现了这个问题。谢谢你的提问!

然而，我发现我在这里看到的答案似乎并没有完全给出你所要求的答案(或者我正在寻找的答案)——它们似乎给出了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日志—图形—一行—全部

(编辑/旁注:添加—装饰也可以很有趣;它添加了分支名称、标记等的指示。没有将它添加到上面的命令行，因为下面的输出没有反映它的使用。)

它显示(假设git配置-global颜色。ui汽车):

或者，直接说:

*   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.用贝壳魔法:

您没有在问题中指定您想要的是类似上述的东西，还是只提供一个修订版本的单一命令，而不是其他任何命令。下面是后者:

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

你也可以把它放到~/中。Gitconfig as(注意:后面的破折号很重要;谢谢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不能工作——<()语法在vanilla sh中不存在。(再次感谢@conny，让我在本页另一个答案的评论中意识到它!)

注:上述备选版本:

感谢liori指出，在比较相同的分支时，上面的内容可能会失败，并提出了一个替代的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' -

从壳上:

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)想到的。这似乎对我有用。它还允许额外的两个别名，这可能会证明很方便:

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

git-ing快乐!

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

测试库

-- 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向我展示了一种更紧凑的编写示例存储库脚本的方法。

你可以使用下面的命令返回branch_a中最老的提交，master无法访问它:

git rev-list branch_a ^master | tail -1

也许有一个额外的健全性检查，该提交的父节点实际上可以从master访问…

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

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'会使用一个提交消息，例如“merge branch 'branch_A' into master”，这告诉你所有来自第二个父分支(commit^2)的提交都来自'branch_A'，并合并到第一个父分支(commit^1)，也就是'master'。

有了这些信息，你可以找到'branch_A'的第一次合并(这是'branch_A'真正存在的时候)，并找到merge-base，这将是分支点:)

我尝试了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'

然后你可以使用'git branch-point branch_A'

喜欢。)

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

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

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
}

当然我遗漏了一些东西，但在我看来，以上所有的问题都是因为我们总是试图找到历史上的分支点，这导致了各种各样的问题，因为可用的合并组合。

相反，我采用了一种不同的方法，基于两个分支共享很多历史，分支之前的所有历史都是100%相同的，所以我的建议是向前(从第一次提交开始)，寻找两个分支的第一个差异。简单地说，分支点就是找到的第一个差值的父点。

在实践中:

#!/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

它解决了我所有的常规案件。当然，有些边境地区没有被覆盖，但是…你好:-)

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

如果你喜欢简洁的命令，

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甚至没有合并到他的分支中!这就是本文给出的解决方案。

如果您想要的是最后一次提交——这样从起点到分支“A”上最后一次提交的所有路径都要经过C，那么您就需要忽略祖先顺序。这纯粹是拓扑学上的，让您了解从何时开始同时运行两个版本的代码。这时您将使用基于merge-base的方法，在我的示例中，它将返回C1。

我似乎得到了一些快乐

git rev-list branch...master

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

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

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

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

经过大量的研究和讨论，很明显没有什么灵丹妙药能在所有情况下都起作用，至少在当前版本的Git中不是这样。

这就是为什么我写了几个补丁，增加了尾巴分支的概念。每次创建分支时，也会创建一个指向原始点的指针，即tail ref。每当分支重基时，这个ref都会更新。

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

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

要从分支点查找提交，可以使用这个。

git log --ancestry-path master..topicbranch

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

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

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

方法

前往所有分支 收集目标分支和其他分支的mergeBase log和迭代 在mergeBase列表中出现的第一次提交时停止

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

笔记

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

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

下面的命令将显示Commit A的SHA1

git merge-base -fork-point A

有时这实际上是不可能的(除了一些例外情况，您可能幸运地拥有额外的数据)，这里的解决方案不会起作用。

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)

You always know that C1 came before C2 and C3 but you never reliably know if C2 came before C3 or C3 came before C2 (because you can set the time on your workstation to anything for example). B1 and B2 is also misleading as you can't know which branch came first. You can make a very good and usually accurate guess at it in many cases. It is a bit like a race track. All things generally being equal with the cars then you can assume that a car that comes in a lap behind started a lap behind. We also have conventions that are very reliable, for example master will nearly always represent the longest lived branches although sadly I have seen cases where even this is not the case.

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

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 here is also misleading because we as humans read it left to right, root to leaf (ref). Git does not do that. Where we do (A->B) in our heads git does (A<-B or B->A). It reads it from ref to root. Refs can be anywhere but tend to be leafs, at least for active branches. A ref points to a commit and commits only contain a like to their parent/s, not to their children. When a commit is a merge commit it will have more than one parent. The first parent is always the original commit that was merged into. The other parents are always commits that were merged into the original commit.

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可以从每个ref (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提交，你会看到零或多个父字段。如果为0，则表示没有父节点，提交的是根节点(实际上可以有多个根节点)。如果有一个，这意味着没有合并，它不是根提交。如果有多个，则意味着提交是合并的结果，第一个之后的所有父节点都是合并提交。

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)

When both hit A their chain will be the same, before that their chain will be entirely different. The first commit another two commits have in common is the common ancestor and from whence they diverged. there might be some confusion here between the terms commit, branch and ref. You can in fact merge a commit. This is what merge really does. A ref simply points to a commit and a branch is nothing more than a ref in the folder .git/refs/heads, the folder location is what determines that a ref is a branch rather than something else such as a tag.

你丢失历史的地方是合并会根据情况做两件事中的一件。

考虑:

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

在这种情况下，任何一个方向的合并都将创建一个新的提交，其中第一个父节点作为当前检出分支指向的提交，第二个父节点作为您合并到当前分支的分支顶端的提交。它必须创建一个新的提交，因为自它们的共同祖先以来，两个分支都发生了必须合并的更改。

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

此时D (B1)现在拥有来自两个分支(自身和B2)的两组更改。然而，第二个分支没有从B1开始的更改。如果你合并B1到B2的变化，这样它们就同步了，那么你可能会看到这样的东西(你可以强制git合并，但是使用——no-ff):

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

即使B1有额外的提交，也会得到这个结果。只要B2中没有B1中没有的变化，两个分支就会合并。它做了一个快进，就像一个rebase (rebase也吃或线性化历史)，除了不像rebase只有一个分支有一个变更集，它不需要从一个分支应用一个变更集到另一个分支。

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

If you cease work on B1 then things are largely fine for preserving history in the long run. Only B1 (which might be master) will advance typically so the location of B2 in B2's history successfully represents the point that it was merged into B1. This is what git expects you to do, to branch B from A, then you can merge A into B as much as you like as changes accumulate, however when merging B back into A, it's not expected that you will work on B and further. If you carry on working on your branch after fast forward merging it back into the branch you were working on then your erasing B's previous history each time. You're really creating a new branch each time after fast forward commit to source then commit to branch. You end up with when you fast forward commit is lots of branches/merges that you can see in the history and structure but without the ability to determine what the name of that branch was or if what looks like two separate branches is really the same branch.

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

1 to 3 and 5 to 8 are structural branches that show up if you follow the history for either 4 or 9. There's no way in git to know which of this unnamed and unreferenced structural branches belong to with of the named and references branches as the end of the structure. You might assume from this drawing that 0 to 4 belongs to B1 and 4 to 9 belongs to B2 but apart from 4 and 9 was can't know which branch belongs to which branch, I've simply drawn it in a way that gives the illusion of that. 0 might belong to B2 and 5 might belong to B1. There are 16 different possibilies in this case of which named branch each of the structural branches could belong to. This is assuming that none of these structural branches came from a deleted branch or as a result of merging a branch into itself when pulling from master (the same branch name on two repos is infact two branches, a separate repository is like branching all branches).

There are a number of git strategies that work around this. You can force git merge to never fast forward and always create a merge branch. A horrible way to preserve branch history is with tags and/or branches (tags are really recommended) according to some convention of your choosing. I realy wouldn't recommend a dummy empty commit in the branch you're merging into. A very common convention is to not merge into an integration branch until you want to genuinely close your branch. This is a practice that people should attempt to adhere to as otherwise you're working around the point of having branches. However in the real world the ideal is not always practical meaning doing the right thing is not viable for every situation. If what you're doing on a branch is isolated that can work but otherwise you might be in a situation where when multiple developers are working one something they need to share their changes quickly (ideally you might really want to be working on one branch but not all situations suit that either and generally two people working on a branch is something you want to avoid).

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

在创建分支的同时，我还创建了一个名称相同但后缀为-init的标记，例如feature-branch和feature-branch-init。

(这是一个很难回答的问题，这有点奇怪!)

一个简单的方法是使用选项——first-parent来更容易地看到git log -graph中的分支点。

例如，从已接受的答案中取repo:

$ 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

这样就简单多了!

注意，如果repo有很多分支，你会想要指定两个分支进行比较，而不是使用——all:

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

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

这是来自一个分支，该分支在合并回主节点之前有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

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

为什么不使用

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

它提供了分支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的功能)中运行上述操作