我有一个带有master和a分支的存储库，在这两个分支之间有很多合并活动。当分支A基于master创建时，我如何在我的存储库中找到提交?
我的存储库基本上是这样的:
-- X -- A -- B -- C -- D -- F (master)
\ / \ /
\ / \ /
G -- H -- I -- J (branch A)
我正在寻找修订A，这不是git merge-base(——all)找到的。
当前回答
当然我遗漏了一些东西，但在我看来，以上所有的问题都是因为我们总是试图找到历史上的分支点，这导致了各种各样的问题，因为可用的合并组合。
相反，我采用了一种不同的方法，基于两个分支共享很多历史，分支之前的所有历史都是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
它解决了我所有的常规案件。当然，有些边境地区没有被覆盖，但是…你好:-)
其他回答
下面实现了等价于svn log——stop-on-copy的git，也可以用来查找分支的起源。
方法
前往所有分支 收集目标分支和其他分支的mergeBase log和迭代 在mergeBase列表中出现的第一次提交时停止
就像所有的河流都流向大海，所有的分支都流向主人，因此我们在看似不相关的分支之间找到了合并基地。当我们从分支头通过祖先返回时，我们可以在第一个潜在的合并基点上停下来，因为理论上它应该是这个分支的原点。
笔记
我还没有尝试过这种兄弟分支和兄弟分支相互合并的方法。 我知道肯定有更好的解决办法。
详细信息:https://stackoverflow.com/a/35353202/9950。
你可能正在寻找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"
问题似乎是在一边的两个分支之间找到最近的单次提交切割，在另一边找到最早的共同祖先(可能是回购的初始提交)。这符合我对“分支”点的直觉。
记住，使用普通的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 log --pretty=oneline master > 1
git log --pretty=oneline branch_A > 2
git rev-parse `diff 1 2 | tail -1 | cut -c 3-42`^
