0

I have sent a PR and that is merged to the repository. Suppose that PR no. is 127 and that PR contained following commits in order (most recent first)

hdyw6
cnsfg

and then I sent another PR no. 128 which had following commits in it

6dwiu
sbyww

(suppose there was only one commit in PR no. 126 i.e. commit jdus7)

Now I realized something wrong got committed and now I want to bring back the repository to the stage just before PR 127. That means I want to keep the commit till jdus7 (that was in PR no. 126)

So how to do that?

Would I have to keep reverting commit one by one (starting from most recent), something like this?

git revert sbyww
git revert 6dwiu
git revert cnsfg
git revert hdyw6

and now finally all bad commits are gone? Please correct me if that is not it will work or any better way to do that?

Or there is something where instead of reverting one by one I just say git reset back till jdus7

JVK
  • 3,782
  • 8
  • 43
  • 67
  • Take a look at this: http://stackoverflow.com/questions/3639115/reverting-to-a-specific-commit-based-on-commit-id-with-git – Steven Spasbo Feb 13 '14 at 19:57

3 Answers3

0

git reset --hard jdus7

git revert is used for another thing (introducing new commit reverting changes of a previous commit).

elmart
  • 2,324
  • 15
  • 17
  • After that if I send a PR then it will ask me to rebase and will fail, isn't it? – JVK Feb 13 '14 at 20:00
  • Yes. If you own the other repository, then you can git push -f to force whatever you want there. Though changing published branches is bad practice since it makes everyone depending on that to have to rebase. If you don't own the other repository, then you simply cannot go back in time. Published is published. You'd have then to use the git revert approach. Or better, just add a new commit fixing the wrong code. – elmart Feb 13 '14 at 20:08
0

If you just want to completely wipe something out of your current branch then you probably want

git reset --hard jdus7

This will make the specified jdus7 id the new HEAD. The command git revert (as you saw) will create a string of new commits on top of the commit you're working back to. This can make for ugly history and leaves a potential landmine for future commits.

If you revert a commit then no change from that commit will ever be merged in. So if you revert commit 123456 and then later run git merge 123456 it will not actually merge anything. This can be really confusing. In order to bring in the changes you must find the revert commit that resulted from git revert 123456 and then revert that commit.

Note though, if you use git reset --hard then the removed commits are no longer accessible from your current branch. When using git revert they will still be there, along with the revert commit.

asm
  • 8,758
  • 3
  • 27
  • 48
0

If the branch is local only, you can just do git reset --hard jdus7

However, if the commits have been pushed to a remote branch this will only move you local back and not actually remove the commits (unless you do a git push -f but you should only do this if you are the only person using the remote as it will mess up the history for people)

You can create a "multi-commit revert" by using this command:

git diff HEAD..jdus7 --name-only | xargs git checkout jdus7 --

This will get the files that have changed and check them out from the state that you want. You can then commit these changes and you will have reverted everything back to the commit that you want.

Schleis
  • 41,516
  • 7
  • 68
  • 87