简体繁体 English

变基导致的孤立提交的命运

[英]Fate of orphaned commits resulting from a rebase

原文 2022-09-20 01:43:06 6 1 git

Consider the (common) scenario of using the rebase command explained here .考虑使用此处解释的 rebase 命令的（常见）场景。 As described in that reference, rebase leads to the creation of new commits corresponding to those in the original feature branch.如该参考中所述，rebase 会导致创建与原始功能分支中的提交相对应的新提交。

I wonder what happens to the commits on the original feature branch.我想知道原始功能分支上的提交会发生什么。 Are they automatically removed during the rebase operation, or will they stay around until a garbage collection operation is performed?它们是在变基操作期间自动删除，还是会一直保留到执行垃圾收集操作？

Note.笔记。 I know it is not too difficult to run an experiment to get the answer to the above question.我知道进行实验来获得上述问题的答案并不难。 I do not have a handy repository ready and am trying to save some time here by relying on the knowledge of others!我没有准备好方便的存储库，我试图依靠其他人的知识来节省一些时间！

1 个解决方案

As Tim Biegeleisen said in a comment , they stick around for a while, because git reflog hangs on to their hash IDs.正如Tim Biegleisen 在评论中所说，他们坚持了一段时间，因为git reflog挂在他们的 hash ID 上。 Other things (eg, ORIG_HEAD or other branch or tag names) may also keep the rebased commits reachable.其他东西（例如， ORIG_HEAD或其他分支或标签名称）也可能使重新定位的提交保持可访问性。

Once the reflog entries and any other way of finding the commits are all gone, git gc may eventually erase them.一旦 reflog 条目和任何其他查找提交的方式都消失了， git gc最终可能会删除它们。 In your own local repository, various Git operations run git gc --auto , which checks to see whether Git thinks it's a good idea to do a git gc now. In your own local repository, various Git operations run git gc --auto , which checks to see whether Git thinks it's a good idea to do a git gc now. If not, git gc --auto quietly exits without doing anything.如果没有， git gc --auto安静地退出而不做任何事情。 Otherwise, git gc --auto does an automatic, background garbage-collection pass.否则， git gc --auto会自动执行后台垃圾收集过程。

Some Git repositories (specifically those created with --bare ) normally have reflogs disabled .一些 Git 存储库（特别是使用--bare创建的存储库）通常禁用reflogs。 In this case, the commits abandoned by git rebase can go away sooner:在这种情况下，被git rebase放弃的提交可以更快地离开 go：

By default, git gc protects any "loose" object for a minimum of 14 days from its creation.默认情况下， git gc保护任何“松散”的 object 自创建后至少 14 天。
By default, a reflog entry sticks around for at least 30 days, or 90 days, depending on whether the hash ID named by the reflog entry is "reachable" from the tip commit named by the reference whose log this reflog entry lives in.默认情况下，一个 reflog 条目至少保留 30 天或 90 天，具体取决于该 reflog 条目命名的hash ID 是否可以从该 reflog 条目所在日志的引用所命名的提示提交中“访问”。

So in a normal (non-bare) repository, commits live on for at least 30 days, and even in a bare repository, commits generally live on for at least 14 days.因此，在普通（非裸）存储库中，提交至少存在 30 天，即使在裸存储库中，提交通常也至少存在 14 天。 But all of these are tunable.但所有这些都是可调的。 This also doesn't cover the dance that occurs when an object (commit or other object) becomes packed , which is more complicated but doesn't shorten the lifetime here.这也不包括当 object （提交或其他对象）变为packed时发生的舞蹈，这更复杂但不会缩短此处的生命周期。

Some hosting sites—GitHub in particular act this way— never expire a commit, so as long as you know its hash ID, you can find it there.一些托管站点（尤其是 GitHub 就是这样操作的）永远不会使提交过期，因此只要您知道它的 hash ID，就可以在那里找到它。