814

Given a change that has been committed using commit, and then reverted using revert, what is the best way to then undo that revert?

Ideally, this should be done with a new commit, so as to not re-write history.

JimmidyJoo
  • 10,503
  • 7
  • 27
  • 30
  • 4
    Possible duplicate of [How can I fix a reverted git commit?](http://stackoverflow.com/questions/5354682/how-can-i-fix-a-reverted-git-commit) – phuclv Apr 11 '17 at 12:14
  • 2
    @phuclv a comment for possible duplicate there, points here. One must be marked original and one must be marked dupliate – John Demetriou May 18 '20 at 12:11
  • @JohnDemetriou no the question that has a better set of answers should be kept open. Time isn't relevant here [How should duplicate questions be handled?](https://meta.stackexchange.com/q/10841/230282) – phuclv May 18 '20 at 12:24
  • 2
    I didn't say about time. I just happened to comment on one of the two about the issue – John Demetriou May 18 '20 at 12:27

14 Answers14

918

git cherry-pick <original commit sha>
Will make a copy of the original commit, essentially re-applying the commit

Reverting the revert will do the same thing, with a messier commit message:
git revert <commit sha of the revert>

Either of these ways will allow you to git push without overwriting history, because it creates a new commit after the revert.
When typing the commit sha, you typically only need the first 5 or 6 characters:
git cherry-pick 6bfabc

Stephan
  • 16,509
  • 7
  • 35
  • 61
  • 107
    This is easily the most elegant and complete solution to the OPs question. Much better than the accepted answer with it's assumptions about the revert commit being at the HEAD of the commit tree. The op also specifically asked for a solution that does not rewrite history so the hard solution offered in the accepted answer is simply wrong. – Timo Oct 22 '15 at 10:39
  • 10
    @Timo To clarify, the accepted answer contains the solution I used ("reverting the revert"), and was posted within hours of my question -- a clear *3 years earlier* than this answer. Hence, the check mark. – JimmidyJoo Aug 23 '17 at 00:38
  • Using -s recursive -X theirs will allow cherry-pick (or rebase) to reuse the commits in some cases where it might otherwise not. For example when you have a branch that got introduced and merged too soon, later the merge commit is reverted. Still sometime later you want to recover those commits. – Rik Renich Nov 13 '17 at 20:30
  • 19
    @JimmidyJoo I know i was 3 years late, I just wanted people coming here from a google search to see a better answer – Stephan Mar 02 '19 at 23:08
  • 3
    @Stephan Yep, but again, to clarify -- it's a better answer just not the one I used to solve my problem. I was simply commenting on why the check mark is where it is. Question to all: does SO convention dictate that I should "maintain" my past questions and re-assign check marks as new answers come in? – JimmidyJoo Mar 04 '19 at 13:05
  • If you cherry-pick the commit, then revert the commit. Once you want redo the commit again, the cherry-pick will do nothing. – Ninja Apr 23 '19 at 05:38
  • 13
    @JimmidyJoo I have no idea about SO convention. But as a google searcher, I really prefer to see the better answer checked. And would appreciate anyone's efforts to maintain their past questions. – Paiman Roointan Jul 29 '19 at 19:35
  • 1
    @JimmidyJoo I think the original answer should be edited to reflect the changing times, at least that's what I try to do, if he/she fails to do that then the new better answer takes over and should be checked. At least that's what I always do. – Timo Huovinen May 05 '20 at 09:34
  • `` what if the revert is done through pull/merge request, use the sha of the commit itself or the sha of the merge commit? – adnanmuttaleb May 01 '21 at 22:51
  • 2
    @adnanmuttaleb https://stackoverflow.com/a/53693507/2063755 explains it perfectly. – David Klempfner Jan 06 '22 at 22:54
  • This is very helpful if you've just accidentally reverted the initial commit of your Msc Project – Kaleba KB Keitshokile Aug 27 '22 at 04:59
528

If you haven't pushed that change yet, git reset --hard HEAD^

Otherwise, reverting the revert is perfectly fine.

Another way is to git checkout HEAD^^ -- . and then git add -A && git commit.

Community
  • 1
  • 1
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 9
    Note that if you want to un-revert without immediately applying the original changes to the master branch, you can (1) restore the original branch if deleted, (2) click "revert" **on the revert branch** as noted by Adam, then (3) click "edit" in the header of the resulting PR and change the target branch to the original branch instead of master. Now your original branch can be re-merged to effect the previously reverted changes. – pauljm Sep 26 '14 at 16:01
  • Yes, reverting a reverted commit is analogous to reinstating that commit. Thank you! – Kedar Mhaswade Mar 26 '15 at 16:16
  • 3
    Please note this will remove all changes in working tree and index. Use git stash to save any changes you don't wan't to lose. – zpon Aug 30 '16 at 05:37
  • 4
    What's the advantage of the checkout && commit method? It seems that in the general case `git cherry-pick` or alternatively `git revert` are the most straight-forward ways to revert a revert. – Robert Jack Will Jan 04 '18 at 17:59
  • Erm ... shouldn't that be `git reset --hard HEAD~`? – Olumide Apr 11 '18 at 15:47
  • @Olumide : they are the same when you only provide 1 ~ or ^. You can find a good answer on it here: https://stackoverflow.com/a/2222920/222134 – Johny Skovdal Sep 29 '18 at 19:32
  • 9
    I think it would be helpful to show how to: `Otherwise, reverting the revert is perfectly fine.`, and then also to explain what `git checkout HEAD^^ -- .` is doing. – Todd Jan 14 '19 at 19:34
  • 7
    Good lord, don't use `git add -A` ...unless you want to add every file to version control, which is most likely not what you want. – Kaitain Jan 29 '20 at 23:37
  • I mis-reverted to HEAD~2 and did this. I lost the most recent commit. Thankfully I have a backup, but `git reset --hard HEAD^` is dangerous. Don't do it unless you're willing to lose all the future commits. – irene Dec 27 '20 at 18:01
  • @Todd -- in checkout is used to separate tree from file. According to the answer here https://stackoverflow.com/a/13321491. – Xiao Jul 20 '21 at 07:32
  • Thanks my aim was to suggest the author provide a more detailed explanation so folks arent just cargo cult copy pasting commands into REPLs and hoping their repo works. – Todd Jul 21 '21 at 21:00
76

A revert commit is just like any other commit in git. Meaning, you can revert it, as in:

git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746

That obviously only makes sense once the changes were pushed, and especially when you can't force push onto the destination branch (which is a good idea for your master branch). If the change has not been pushed, just do cherry-pick, revert or simply remove the revert commit as per other posts.

In our team, we have a rule to use a revert on Revert commits that were committed in the main branch, primarily to keep the history clean, so that you can see which commit reverts what:

     7963f4b2a9d    Revert "Revert "OD-9033 parallel reporting configuration"
     "This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
                    ...
     a0e5e86d3b6    Revert "OD-9055 paralel reporting configuration"
     This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
                ...
     Merge pull request parallel_reporting_dbs to master* commit 
    '648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'

This way, you can trace the history and figure out the whole story, and even those without the knowledge of the legacy could work it out for themselves. Whereas, if you cherry-pick or rebase stuff, this valuable information is lost (unless you include it in the comment).

Obviously, if a commit reverted and re-reverted more than once that becomes quite messy.

Nestor Milyaev
  • 5,845
  • 2
  • 35
  • 51
41

Reverting the revert will do the trick

For example,

If abcdef is your commit and ghijkl is the commit you have when you reverted the commit abcdef, then run:

git revert ghijkl

This will revert the revert

saeedgnu
  • 4,110
  • 2
  • 31
  • 48
Rafeeque
  • 845
  • 9
  • 13
  • 2
    This is the correct answer. It also clarifies that a revert is a commit itself that ca be reverted. – MoMo Sep 09 '21 at 10:15
9

If you did a revert by mistake:

git revert <commit-id>

you will simply need to run:

git cherry-pick <commit-id>

I had to commit my changes to processed with this command.

You can get your commits ID by running:

git log --pretty=format:"%h - %an, %ar : %s"
Affes Salem
  • 1,303
  • 10
  • 26
8

Here's how I did it:
If the branch my_branchname was included in a merge that got reverted. And I wanted to unrevert my_branchname :

I first do a git checkout -b my_new_branchname from my_branchname.
Then I do a git reset --soft $COMMIT_HASH where $COMMIT_HASH is the commit hash of the commit right before the first commit of my_branchname (see git log)
Then I make a new commit git commit -m "Add back reverted changes"
Then I push up the new branch git push origin new_branchname
Then I made a pull request for the new branch.

Drew LeSueur
  • 19,185
  • 29
  • 89
  • 106
  • Way to go when there are too many "cherry-pick" to do. I don't get why this answer has so few upvotes – Fundhor Oct 29 '18 at 16:18
5

If you don't like the idea of "reverting a revert" (especially when that means losing history information for many commits), you can always head to the git documentation about "Reverting a faulty merge".

Given the following starting situation

 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E   <-- fixed-up topic branch

(W is your initial revert of the merge M; D and E are fixes to your initially broken feature branch/commit)

You can now simply replay commits A to E, so that none of them "belongs" to the reverted merge:

$ git checkout E
$ git rebase --no-ff P

The new copy of your branch can now be merged to master again:

   A'---B'---C'------------D'---E'  <-- recreated topic branch
  /
 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E
NobodysNightmare
  • 2,992
  • 2
  • 22
  • 33
  • Good idea and thanks for the doc link. We usually rebase with master before merging back in, but git then seems to recognize that A', B', C' are the same as the ones before, and I now have D, E after W ([pastebin](https://paste.ubuntu.com/p/73wwbM9cbh/)). Suggestions on how to solve this? – Kristoffer Bakkejord Jun 28 '19 at 07:31
2

Or you could git checkout -b <new-branch> and git cherry-pick <commit> the before to the and git rebase to drop revert commit. send pull request like before.

Ryan Chou
  • 1,086
  • 11
  • 21
2

To get back the unstaged and staged changes which were reverted after a commit:

git reset HEAD@{1}

To recover all unstaged deletions:

git ls-files -d | xargs git checkout --
jkdev
  • 11,360
  • 15
  • 54
  • 77
0

I had an issue somebody made a revert to master to my branch, but I was needed to be able to merge it again but the problem is that the revert included all my commit. Lets look at that case we created our feature branch from M1 we merge our feature branch in M3 and revert on it in RM3

M1 -> M2 -> M3 -> M4- > RM3 -> M5
 \.         /
  F1->F2 -

How to make the F2 able to merge to M5?

git checkout master
git checkout -b brach-before-revert
git reset --hard M4
git checkout master
git checkout -b new-feature-branch
git reset --hard M1 
git merge --squash brach-before-revert
0

After the initial panic of accidentally deleting all my files, I used the following to get my data back

git reset HEAD@{1}         
git fsck --lost-found      
git show 
git revert <sha that deleted the files>
TT.
  • 15,774
  • 6
  • 47
  • 88
Jay
  • 1
0

I saw responses include the command git reset --hard HEAD without any caution. You should be careful with that command because of the option --hard. It resets your index and your remote repo but mostly, it also resets your local repo and all commits that were not pushed to the remote yet will be lost, both from your local repo and index. Never use that flag --hard unless you are sure you also want to reset all your local work from the current commit till the hash you chose. If anyway you did it by mistake, run git reflog to retrieve your ~hash then git reset --hard ~hash to recover your files.

legrand
  • 1
  • 2
0

In my case I needed to commit the changes after revert before I could cherry-pick the original commit without a failure.

git commit -m "Make changes (original commit)."
git revert <original commit hash>
git commit -m "Revert original commit."
git cherry-pick <original commit hash>
Kaleb Coberly
  • 420
  • 1
  • 4
  • 19
-1

spring was then undone
as the seasons always change
revert of revert

Guildenstern
  • 2,179
  • 1
  • 17
  • 39