Git Internals

Reachability and Garbage Collection

Whether objects can still be recovered often depends more on reachability and garbage collection than on the command that made them harder to find.

An object still existing in the repository is not the same as that object still being easy to reach.

What reachability means

If an object can still be reached from branches, tags, HEAD, or reflog history, it is usually easier for Git to retain and for you to recover.

Why recovery often works after mistakes

After reset, rebase, or merge, old objects often do not disappear immediately. What you lose first is frequently the obvious name, not the underlying data.

Why you still should act quickly

Over time, unreachable objects can be collected. That is why recovery gets harder if you wait too long after a destructive mistake.

Related Reads

Git Object Database

Understand blob, tree, commit, and tag objects, and why Git describes itself as a content-addressable object database.

Working Tree, Index, and Object Store

Separating the working tree, index, and object database is the clearest way to understand add, commit, restore, and reset.

Git References and HEAD

Put branches, tags, remote-tracking refs, and HEAD into one model so Git's pointer behavior becomes easier to reason about.

PreviousGit Packfiles and Object Storage

Learn how Git uses packfiles, compression, and object reuse to store and transfer history efficiently instead of copying full project snapshots every time.

NextMerge Bases and Ancestry

Explain how Git uses common ancestors to reason about branch differences, merge inputs, and reachability.