推送后恢复丢失的提交

Question

I could use some help with a recovery strategy. Somehow we ended up in a position where one commit dropped about 3 days worth of commits. And then got pushed . The committer isn't sure whether he did forced the push or what, but now we're in this position. And about 10 additional commits have been pushed since the "bad" one.

All of the old commits are there and I could piece everything back together, but I'm hoping that Git can help me out. I suppose I could cherry-pick the range of commits between point A and point B, but is there anything better? Most, but not all, of the changes are local to one directory and I'd rather not manually inspect each one.

What's the right approach here remembering that everything has been pushed upstream?

Answer 1

git reset --hard <one commit before the bad commit>
git cherry-pick <the range of commits you've lost>
git pull

This way you simulate that you are on the last good commit (with the reset ). Then you create new commits locally ( cherry-pick ). Now you pull in changes (and maybe merge conflicts).

Answer 2

You might be interested in checking git reflog of either the upstream or your local repo. Even if the commits look like they're lost, they might actually still be hanging around in your remote/local repos, just without a branch pointer on them. They won't stay like that forever though, I think git does garbage collection every 2 weeks by default :

The optional configuration variable gc.pruneExpire controls how old the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago".

You can read more about using the reflog to recover lost work at Pro Git §9.7: Maintenance and Data Recovery .

if you find the commits in the reflog (or you might want to also look for them in git fsck --full ), you can attach a branch pointer to them to "recover" them. Then you might want to rebase or cherry-pick newer commits on top in order to (re)construct whatever commit history tree you want.

Answer 3

git revert将在新提交中撤消提交的更改。