0

In GitHub, I accidentally merged the wrong branch into master. (probably from a slip of the finger when selecting from the dropdown) The merge was completed and pushed before I realized my error.

I've looked at:

Reverting a bad git merge from GitHub

Github: Changes ignored after revert

GitHub revert or reset?

Reverting a git merge commit, then reverting the revert

Github Revert. Unsure about history

But none of them successfully addressed the issue, and unless I'm misunderstanding something, they all indicate that the revert should have undone the bad merge, leaving me ready to re-merge the proper branch later on.

My structure is like this:

/master

/dev_2.0

/test_2.0

/dev_3.0

/test_3.0

All branches are branched off of /master. Each test release, dev_x.0 is pushed to test_x.0 and at each final prod release, test_x.0 is merged to master.

We have a tag (call it test_tag_2.0) on the test_2.0 branch which reflects the test_2.0 branch at deployment time. Version 2.0 has gone to production and is completed, 3.0 has development ongoing.

/master, for us, is used exclusively for deployed code, and is not touched by anyone but me. No danger of subsequent commits exists in master. No further development is ongoing in test_2.0.

What I wanted to do is to roll back the bad merge (test_3.0 -> master) to the state it held prior to the merge, and perform a correct merge (test_2.0 -> master)

Per the advice on several topics on Stack Overflow, I performed a reset on my local repo to undo the bad commit, and pushed it to remote. In GitHub, it shows a successful revert in history. gitk shows the revert as well.

Here's the command I did:

`git reset --hard HEAD@{1}`

Then pushed to remote

However, now when I compare master to the incorrect source branch test_3.0, it shows that master is current with all changes on that branch. Shouldn't the revert have undone that?

It also still shows that master is current with the correct branch test_2.0, after the revert I performed. Shouldn't it also show that this is not the case?

So the end result I want is for the master branch to be completely identical in all ways to the way it was prior to the bad merge, and for a fresh merge from the correct test_2.0 branch to master to be successful.

MarkTO
  • 247
  • 2
  • 11
  • So I tried recreating this in a sandbox project, so I could experiment, and what happens there is that I can perform the reset, but I can't push the reset to GitHub because the reset local master branch no longer shows all the changes that exist in remote master branch. So that completely defeats the purpose of the reset. I'm TRYING to get rid of the newer items in remote master, not ensure they're preserved. – MarkTO Jun 11 '18 at 20:48
  • 1
    you need to force-push in a situation like this. https://stackoverflow.com/questions/5509543/how-do-i-properly-force-a-git-push – Ringo Feb 28 '19 at 10:52

0 Answers0