Consider the (common) scenario of using the rebase command explained here. As described in that reference, rebase leads to the creation of new commits corresponding to those in the original feature branch.

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!

CodePudding user response：

As Tim Biegeleisen said in a comment, they stick around for a while, because git reflog hangs on to their hash IDs. Other things (e.g., ORIG_HEAD or other branch or tag names) may also keep the rebased commits reachable.

Once the reflog entries and any other way of finding the commits are all gone, git gc may eventually erase them. 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. Otherwise, git gc --auto does an automatic, background garbage-collection pass.

Some Git repositories (specifically those created with --bare) normally have reflogs disabled. In this case, the commits abandoned by git rebase can go away sooner:

• By default, git gc protects any "loose" object for a minimum of 14 days from its creation.
• 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.

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. 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.

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.