Von Gast (nicht überprüft) , 29 April 2026

Was Sie erreichen werden

Sie werden absichtlich einen Rebase vermurksen und dann mit Reflog und ORIG_HEAD wiederherstellen.

Setup: ein Sandbox mit echten Commits

mkdir rebase-recovery && cd rebase-recovery
git init
for i in 1 2 3 4 5; do
  echo "$i" > file.txt
  git add . && git commit -m "Commit $i"
done
git log --oneline

Katastrophe 1: versehentlich gedroppte Commits

git rebase -i HEAD~4
git log --oneline

Wiederherstellung 1: ORIG_HEAD

git reset --hard ORIG_HEAD
git log --oneline

Katastrophe 2: Rebase-Konfliktauflosung schiefgegangen

git checkout -b feature HEAD~2
echo "feature change" >> file.txt
git commit -am "Feature change"
git rebase main

Wiederherstellung 2: Reflog

git reflog
git reset --hard HEAD@{3}

Katastrophe 3: Rebase, dann mehr Arbeit, dann erkannt, dass Rebase falsch war

git reflog
git reset --hard <sha-before-rebase>
git branch save-work HEAD~2..HEAD
git reset --hard <sha-before-rebase>
git cherry-pick save-work
git branch -D save-work

Katastrophe 4: schlechten Rebase force-gepushed

git reflog
git reset --hard <good-sha>
git push --force-with-lease

Katastrophe 5: Rebase hat den falschen Elternteil gefressen

git reset --hard ORIG_HEAD
git rebase main

Zukunftige Katastrophen verhindern

Backup-Branch vor riskanten Operationen

git branch backup-before-rebase
git rebase -i HEAD~10
git reset --hard backup-before-rebase
git branch -D backup-before-rebase

Reflog-Ablauf erhohen

git config gc.reflogExpire 365.days
git config gc.reflogExpireUnreachable 90.days

Vor dem Rebase pushen

git push backup HEAD:my-branch-backup
git rebase ...

Rerere aktivieren

git config --global rerere.enabled true