Does Git's Default Reflog Window Make Schema-Change Rollback Safe?

Answer first

No. The default 90-day reflog window is not a dependable safety net for rolling back schema-change commits weeks or months later, and raising gc.reflogExpire alone does not make it reliable.

Reflog is local and ephemeral. It can help you find a lost HEAD position on the exact clone where the operation happened, within the retention window. It does not provide shared, long-term recoverability for a team, and it does not help when the commit hash is unknown and the entry has expired.

Confirmed facts

• Reflog records HEAD movements per repository. It is stored in .git/logs/ and is not pushed to a remote.
• Retention is controlled by gc.reflogExpire and gc.reflogExpireUnreachable. The commonly cited default is 90 days for reachable reflog entries, with a longer default for unreachable entries. Exact defaults can vary by Git version and existing config.
• Each clone has its own reflog. A new clone starts with an empty reflog.
• git reset --hard moves HEAD and discards working tree changes. It does not delete commits immediately, but recovery after the reflog expires depends on knowing the commit hash.
• git revert creates a new commit that undoes a previous commit. It requires identifying the exact commit to revert.

Likely explanation and limits

For a migration-heavy repository the risk is per-clone isolation and expiry. If the developer who applied the migration deletes their clone, runs aggressive git gc --prune=now, or the 90-day window passes, the reflog entry that points to the pre-migration state disappears. The commit may still exist in the object database until garbage collection, but without a reference it becomes unreachable and eventually unrecoverable.

Raising gc.reflogExpire lengthens the window on that clone only. It does not create a shared safety net.

Steps that preserve recoverability when the hash is unknown

1. Protect the pre-migration point with a shared reference before the change lands. Example: git tag schema/pre-2026-10-15 origin/main and push the tag.
2. If you must rely on reflog, find the entry on the original clone while it is still retained: git reflog --oneline -n 50. Note the commit hash, then create a permanent reference: git branch schema-rollback- and push it.
3. For rollback, prefer git revert -m 1 on a shared branch rather than git reset --hard, which rewrites history.

Assumption: you are using Git 2.x with standard garbage collection behavior. Uncertainty remains around the exact default values on your installations; verify with git config --get gc.reflogExpire.

One diagnostic that changes the recommendation: are migration commits required to be recoverable across all team clones and CI environments, or only on a single long-lived operations clone? If cross-clone recovery is needed, reflog is unsuitable and tags/protected branches or an external backup are required.