1

让我们使用最新的可用 git 2.16.2 和 tig 2.3.3。

cd /tmp && mkdir fit && cd fit

git init
touch m1 && git add m1 && git commit -m "master 1"
touch m2 && git add m2 && git commit -m "master 2"
git checkout -b develop
touch d1 && git add d1 && git commit -m "develop 1"
git checkout master
touch m3 && git add m3 && git commit -m "master 3"
git checkout develop
git merge master --no-edit
touch d2 && git add d2 && git commit -m "develop 2"
touch d3 && git add d3 && git commit -m "develop 3"
git checkout master
git merge develop --no-edit
touch m4 && git add m4 && git commit -m "master 4"

git reflog expire --expire=now --all && git gc --prune=now --aggressive

泰格 在此处输入图像描述

检索分支中的最后一次提交非常容易：develop

git --no-pager show -s --format=%B $(git rev-parse develop)

开发 3

但我无法检索分支中的第一个提交。develop所以我找不到分支分支的提交。

git merge-base --fork-point develop
git rev-list develop..master
git rev-list develop master
git rev-list master develop
git rev-list ^develop master

结果是没有用的。

我找到了一个问题的解决方案如何在合并的分支分支的地方获得提交

git oldest-ancestor master develop
git oldest-ancestor develop master

结果也没有用。

但是tig并且git log --graph仍然能够看到这develop 1是该分支的第一次提交，并且develop该分支是从.master 2master

master 2是否可以使用当前的 git 控制台工具进行检索？

4

1 回答 1

3 
git --no-pager show -s --format=%B $(git rev-parse develop)

更简单：

git --no-pager show -s --format=%B develop

或者：

git --no-pager log --no-walk --format=%B develop

（show -s并且log --no-walk几乎是同一件事；这里的关键是删除不必要的git rev-parse）。

但我无法检索分支中的第一个提交develop

该分支中的第一个提交是master 1，或者27ee6b8在您的图像中（哈希 ID 会随着提交的时间而变化）。这也是 branch 中的第一次提交master。

这里的问题是分支没有“起点”。从某种意义上说，分支是一个结构——图形片段——通过从终点开始并回到起点而达到。这意味着一些提交在许多分支上；通常，根提交，即您在存储库中所做的第一次提交，位于每个分支上（尽管在具有多个根的存储库中，某些根可能不在某些分支上）。

通常，分支名称（也有一些例外）与该分支上的提示提交同义，这就是为什么您不需要显式的git rev-parse. 然而，分支名称的关键特征是它会随着时间移动，因此它总是命名分支的尖端提交。

另请参阅“分支”到底是什么意思？

如果您希望标记某个特定的提交，以便以后记住它，通常的工具是 Git 标记。标签与分支名称非常相似，因为它标识了一个特定的提交。然而，与分支名称不同的是，标签永远不会移动，Git 不会自动移动它。

git reflog expire --expire=now --all

Reflogs 的存在专门用于观察引用的移动（随着时间的推移）。分支名称的 reflogdevelop默认情况下会保留 30 或 90 天1develop 用于标识的哈希 ID 。通过使它们过期，您已经失去了回到过去查看develop@1、等的能力develop@2。如果您保留了它们，您可以寻找最古老develop的存在。那可能是它诞生的时候，你经常可以说：

05d0c47 master@{37}: clone: from ...

（表示master此时出生）。

不幸的是，reflogs确实会过期，所以这并不完全可靠。标签是可靠的，但可能很烦人，因为git log会用他们的标签装饰提交。如果有查找有趣提交的过程，您可以使用它。在这种情况下，有这样一个过程：您想要曾经或曾经是合并的合并基础的提交。

要找到合并基，先找到合并本身，然后找到它的父项：

m=11c63bc  # this is the merge
p1=$(git rev-parse ${m}^1)
p2=$(git rev-parse ${m}^2)

现在$p1和$p2是这个合并的两个父母。（合并可以有两个以上的父级，但大多数合并只有两个。）这两个分支最后合并的共同点是两个父级的合并基础：

git merge-base --all $p1 $p2

由于只有一个合并基础，因此只打印一个提交哈希。如果有几个，它会打印所有的，因为我们使用了--all. 省略--all，我们会（显然）随机选择一个（实际选择的一个取决于用于查找合并基的算法）。

和以前一样，不需要很多临时变量——我们可以这样做：

mbases=$(git merge-base --all ${m}^1 ${m}^2)

因为git merge-base采用与 : 相同的提交说明符语法git rev-parse：^1和^2后缀在那里工作相同（并且在大多数 Git 命令中确实工作相同）。

1过期时间是可配置的。较短的时间（默认为 30 天）适用于从引用的当前值无法访问的哈希 ID；较长的 90 天默认值适用于可从引用的当前值访问的哈希 ID。

于 2018-03-15T23:04:56.100 回答