3

Our git branch pipeline is

dev -> test -> uat -> master

where test, uat and master are protected branches.

I have some faulty merges done uptil uat. I would like to revert them. I tried using rebase instead of revert because I was not able to find the n in HEAD~{n} uptil which i can revert all my commits and merges.

git revert HEAD~n

So I tried to do rebasse instead. I found the good commit to development till which everything was normal. I used

git rebase -i good_commit_sha

I see a list of all commits (mostly bad) and i drop all of them and pick 2 which were good. But when i see the merge request, I only see the ones I picked (naturally). So i realized that instead of drop i wanted to revert. Is that possible?

I know this is not a good practice but open to suggestions and i do think this is a common scenario.

technazi
  • 888
  • 4
  • 21
  • 42

3 Answers3

2

I have some faulty merges done uptil uat. I would like to revert them. I tried using rebase instead of revert because I was not able to find the n in HEAD~{n} uptil which i can revert all my commits and merges.

git revert HEAD~n

This is your actual problem, and we'll try to give a solution for that.

To git revert after a merge, you'll have to specify a few options as stated in the docs and as explained in this answer. You'll have to specify the side of the merge to revert to, otherwise the statement would be umbiguous. This tutorial by Linus himself shall be helpful.

Your syntax should be the following:

git revert -m 1 <SHA of the commit to revert to>

remember, -m starts counting from 1, you might want to do a few runs locally, then commit and push the "good" one.

Daemon Painter
  • 3,208
  • 3
  • 29
  • 44
0

A good phrase to remember: Rebase locally, merge remotely

Meaning as long as it's not pushed yet, feel free to use (interactive) rebase and fix everything you need to. This can involve deleting commits, squashing them, whatever helps to understand your commit history.

As soon as it is pushed you should use merge because otherwise your would have to force-push your rebased changes later which you should always avoid because someone could already have checked out what you are going to change (talking about the commit history here).

That being said, your way of doing it is one possibility. Reverting the faulty commit later is the other way you could go.
Expecting the faulty commit to already be on your remote, the latter approach should be preferred.

Dominic Frei
  • 327
  • 1
  • 5
-1

I managed to find the answer from another this question on SO. (Finding link)

git reset --hard good_ocmmit_sha

HEAD is now at good_ocmmit_sha fix unit tests

git reset --soft @{1}

git commit -m "Reverted to stable"

[revert_branch ] Reverted to stable

technazi
  • 888
  • 4
  • 21
  • 42
  • 1
    this is now an XYZ: I want to revert (will create a new commit), I don't know how so I'll rebase instead (will create a new history of commits and delete some), but it doesn't work, so I'll git reset instead (I'll have to force push, destroying the history and making a new one) – Daemon Painter Sep 18 '20 at 15:14
  • Thanks for introducing to these concepts. Thanks for the answer above. I will use that instead. I will refrain from asking such loaded questions. Although I did not have to force push, did I do this one wrong as well? – technazi Sep 18 '20 at 15:19
  • 1
    do not apologize, you did the right thing asking, it will greatly help you far beyond the actual technical issue at hand – Daemon Painter Sep 18 '20 at 15:34