合并MR并删除分支后，GitLab是否保留特性分支的原始提交？

这是个很常见的疑问，我来一步步拆解清楚：

1. GitLab的Merge Request会保留原始提交的引用 #

当你创建MR时，GitLab会在仓库内部生成一些隐藏的专用引用，比如 refs/merge-requests/<你的MR编号>/head 或者 refs/merge-requests/<你的MR编号>/diff，这些引用会牢牢指向特性分支的原始提交——哪怕你后来删除了特性分支，这些内部引用依然会存在一段时间。

Git的垃圾回收（GC）只会清理没有任何引用指向的对象（包括提交、blob文件等），只要有这些MR相关的引用在，原始提交就不会被标记为“可回收”，自然能在GitLab的MR页面、diff记录里正常显示。

2. 原始提交不会永久保留，最终会被GC清理 #

GitLab不会无限保留这些孤立的提交，它有一套自动清理机制：

• 对于已经合并或关闭的MR，GitLab会在一段时间后（默认通常是几周，具体取决于实例配置）移除这些MR相关的隐藏引用。
• 当这些引用被移除后，原始提交就变成了无任何引用的孤立对象，下一次GitLab运行仓库的垃圾回收时，这些提交就会被彻底清理掉。

不过有个例外：如果有人把原始提交的哈希复制到了其他地方（比如本地仓库、另一个fork、或者在issue/MR评论里引用了这个哈希），那这个提交会因为有外部引用而继续存在，直到所有指向它的引用都消失。

3. Rebase压缩提交的影响 #

你提到用rebase策略而非merge，这点确实有特殊影响：rebase压缩是创建全新的提交来替换原始提交序列，合并到main后，原始提交其实是和新提交完全独立的“平行历史”。但因为MR的引用还指着原始提交，所以它们不会被立刻清理——这和普通merge后的情况本质是一样的，区别只是rebase生成了新的提交，原始提交更“孤立”而已。

总结一下：GitLab靠MR的内部引用暂时保留原始提交，等过了保留期、没有其他引用时，GC就会把它们清理掉。

内容的提问来源于stack exchange，提问作者uranix