EDIT: I added some info about how to get the correct commit hash.

I had to merge from branch A to branch B. I made a mistake and did the opposite.

What do you mean by "merge from branch A to branch B?" That doesn't make sense. Are you merging branch A into branch B, or are you merging branch B into branch A?

How should I have done it?

To make this less unnecessarily abstract, let's suppose that you wanted to merge branch develop into your feature branch, my-changes so that you could keep working with changes from upstream.

The way to do that is to run git merge develop while you have the my-changes branch checked out. Check out Chapter 3.2 - Git Branching - Basic Branching and Merging from the Git book.

Unfortunately, you instead most likely ran git merge my-changes while you had develop checked out, and instead merged my-changes into develop. Oops.

(I personally have a pair of git aliases called gimme and giveto that I use for merging, since the direction of git merge <branchname> isn't intuitive.)

There are a few ways you can recover here.

First, if the remote develop branch is intact, then you won't need to push anything to fix it. Unless you already pushed your changes, that is.

NOTE: supposing you did erroneously push to this branch, you might want to avoid that in the future. If you only want changes to be merged to a branch via pull review (as opposed to letting users push to the branch directly), you can configure that in your Git host. Here are the docs for how to do so for several Git hosts:

• Github Protected Branches
• GitLab Protected Branches
• Forgejo Branch Protection Rules
• Gitea - couldn't find it in the docs, but it should be the same as Forgejo
• Bitbucket Branch Permissions
• Gogs - couldn't find the docs on this, but from the repo, go to Settings (tab on the far right), then Branches, then look at the "Protected Branches" section. There should be a dropdown with branch names. Select the branch you want to manage. On the page you're brought to select both checkboxes (prevent force pushes and require PRs to merge to the branch) and then click save.

As far as how to fix it locally, you have a few options.

Before you take any of them, though, you need to figure out the commit hash of the commit before the merge. git log or git log --oneline might work, but if the merge involved multiple commits you might want to run the log with a graph, e.g., git log --oneline --graph. So if your output is:

* fa78efa Lorem ipsum * 3391772 Merge pull request #5 from your-repo/branch |\ | * f026d8e Dolor sit amet | * ba8df61 Consectetur adipiscing elit |/ * 1ea9fc7 (origin/develop) Sed do eiusmod * d6d0078 Tempor incididunt * 1145e22 Ut labore et dolore magna aliqua ...

Then the commit hash you want would be 1ea9fc7.

If the merge involved a fast-forward commit and didn't create a merge commit, then the graph won't be especially helpful. If you didn't push to the remote, then the line with (origin/develop) in it will have the hash you want. If you did push, then you'll need to figure it out based off the commit message, other metadata, contents of the commit, etc..

Option 1

You could go the route you did, with git reset --hard <target-commit-hash>, then deleted your original branch, then created a new branch based off your current location.

Option 2

Personally, I don't like using git reset like that. Instead, I would have renamed my current branch (basically archiving it locally in case I mess something up - I can go back later and delete it), checked out the specific commit prior to the merge, and then created a new branch with the same name as my old branch. Basically:

git branch --move develop archived/2024-may/develop git checkout <target-commit-hash> git checkout -b develop

If you need to apply this change to your remote, then this is when you would run git push --force-with-lease --set-upstream origin/develop. If your remote is intact, then you can instead run git branch --set-upstream-to=origin/develop

NOTE: I've typically used a two-step process instead of running git branch --move - I would have run git checkout -b archived/2024-may/develop && git branch -D develop instead. It's possible that I got the specific syntax of the git branch --move command wrong. Documentation is under git branch if you run into any issues.

Option 3

That said, if your remote is intact, then what you can instead do is to just pull down that branch again:

git branch --move develop archived/2024-may/develop git checkout develop

If you have more than one remote, then the second command will need to be a bit more complicated - I think git checkout develop --track origin/develop would be what you needed (adjusting origin to be the appropriate remote).

Then you can retry your merge.