I did a git reset HARD to fix a bad commit, but now my branch is behind

Question

We had someone commit some files that had only partial merges in them. In short, anyone who pulled ended up with a corrupted project.

We solved this by doing a git --reset HARD . Great! The issues is now that we're 2 commits behind. But we DO NOT want those 2 commits. We'd like to pretend that everything after xxyy never happened.

What's the best option here?

Probably this helps: http://stackoverflow.com/questions/1338728/delete-commits-from-a-branch-in-git — Willem Van Onsem, Apr 04 '16 at 06:29
once you've pushed, you can never pretend again that something didn't happen (unless using `git push -f`, but this is considered harmful). Instead, `git revert` the bad commits, then push nicely. — eckes, Apr 04 '16 at 06:32

score 2 · Answer 1 · edited Apr 04 '16 at 06:33

2

You've already fixed the problem, at least locally. But the bad commits still persist on the remote. You basically have two options here:

You can revert the two commits on the remote using git revert:
```
git revert <SHA-1 of commit #1>
git revert <SHA-1 of commit #2>
```
This option will basically add two new commits on the remote branch which will effectively undo whatever the original commits did.
You can do an interactive rebase of the branch and excise out the two commits:
```
git rebase -i
```
In this option you will remove the two bad commits completely. But beward, this will also rewrite the history of the remote branch which might force certain people in your group (yourself included) to delete your local copy of the branch and checkout a completely new version from the remote.

Doing a git revert is possible the safest option since it won't hurt anyone else who has a local copy of the branch in question.

edited Apr 04 '16 at 06:33

Willem Van Onsem

443,496
30
428
555

answered Apr 04 '16 at 06:31

Tim Biegeleisen

502,043
27
286
360

`git revert` is the way to go. With `rebase -i`, you'd need to `git push -f` which is considered a bad thing. – eckes Apr 04 '16 at 06:33
@eckes I agree that this is the safest way to go. Perhaps in his case the remote branch in question is only shared by a few people and force pushing is not a problem. Anyway, I gave the alternative for anyone else who might benefit from it. – Tim Biegeleisen Apr 04 '16 at 06:35
Doing a `git revert` is indeed safe, but then you need to cancel the `git reset --hard` first (e.g. `git pull` to get back the remote commits). It makes no sense to revert commits that do not appear in your own history. – Matthieu Moy Apr 04 '16 at 13:46
Good point. I wrote the answer from the vantage point of what he should have done from the beginning. – Tim Biegeleisen Apr 04 '16 at 13:50

score 0 · Answer 2 · edited May 23 '17 at 11:59

0

The problem is probably that the person pushed those commits to GitHub or another social coding service.

Now when you do a push, the push is rather careful not to delete anything. You can however --force the push to accept history rewrites with:

git push origin HEAD --force

as is explained in this answer.

edited May 23 '17 at 11:59

Community

1
1

answered Apr 04 '16 at 06:31

Willem Van Onsem

443,496
30
428
555

1

Force pushing to a shared repository is considered bad practise. It almost guarantees problems down the road, because others can still base their commits on the removed commits. – Peter Apr 04 '16 at 06:49
@Peter: unless you have a team that interacts about this issue. I'm not saying it is the best solution, but it is *a* solution. – Willem Van Onsem Apr 04 '16 at 07:17

I did a git reset HARD to fix a bad commit, but now my branch is behind

2 Answers2