GitLab 中的合并请求版本是什么？这是特定的 GitLab 功能吗？

Question

在 gitlab 中，如果我有一个开放的拉取请求，其中包含一些提交。在更改面板上，我可以看到带有版本历史记录的下拉列表。

这些版本似乎与分支或合并请求本身相关，因为当我添加新提交或强制推送修改后的提交时，我可以看到版本弹出（这看起来很奇怪，因为强制推送应该重写分支历史记录）

git commit --amend --no-edit
git push origin branch --f

但是除了最新版本之外，我在本地存储库中找不到任何版本引用：

git log 1d2ee59b

给了我日志，但是

git log 1c7b76e4
git log 09dc0bb8

抛出

unknown revision or path not in the working tree.

所以我想知道，这是 GitLab 中的一个功能（比如与 PR/分支相关的某种自定义引用日志，还是我不知道或不理解的 git 功能？

Answer 1

这不是 Git 功能。这意味着它一定是 GitLab 的一个功能。

是的，强制推送确实会重写分支。但我们只考虑一下 git-rebase(1)（本地操作）：变基可能会使旧的提交 从该分支无法访问。然后它们仅存储在引用日志中。和 最终引用日志会过期并且提交会被垃圾收集。但 没有什么可以阻止你进入重写机制 并在每次变基时存储对分支的old提示的引用。或许 像这样：

refs/branch-history/<branch-name>/1
refs/branch-history/<branch-name>/2
refs/branch-history/<branch-name>/3
refs/branch-history/<branch-name>/4

您在“1”上进行第一次变基的地方等等。现在的提交来自 旧分支可以再次到达（通过这些引用），因此永远不会得到 垃圾收集。

GitHub 实际上通过将所有引用写入写入审核日志来保留它们：

是的，我们在 GitHub 面临这个问题。我们实际上写了每一个参考文献 写入 $GIT_DIR/audit_log，它本质上是一个引用日志 前面加上了引用名称。但关键是它永远不会被 git read 为了可达性。所以它成为所发生事件的不可变日志，并且 我们可以愉快地修剪引用日志以删除对象。

现在（自 Git 2.42 起）您可以结合使用

gc.recentObjectsHook

使用这样的文件以保留来自all以前版本的所有提交 活着，有效地实施 GitLab 已经做的事情。你这样做是通过 提供一个钩子程序来打印所有应该保留的提交 活。如果您有该格式的“审核日志”，那么您的程序 只需打印文件即可。