Fixing merge conflicts after committing to the wrong branch

Summary

We've all been there. You've made changes to your project and you're excited to put a button on it and push your commit right away. It's only later when you realize that you've been pushing to the wrong branch. You don't notice the problem until you have a development branch that is ready to complete a design review (pull request), but you have merge conflicts. What do you do?

Merging isn't straightforward

One of the big problems with this scenario is that merging isn't straightforward. Because you're working with 2D ECAD designs, you can't just open up a text browser or merge tool and choose the text that you want. You have to open up your designs in an ECAD tool and manually copy them.

Make a local backup

It is best to make a local copy of your local repo so you can access the files for copying design features from the wrong branch to the correct branch. It may be possible to slice and dice your repo and revert the files back to a previous state, but it is also possible to destroy your changes and no longer have access to them.

It's not the git way, but making a local copy of your files can save you a big headache in the long run.

The scenario

In this example, we make 6 changes to the repo into two different branches, main and develop (dev). The changes are numbered in chronological order and divided between branches as follows:
Develop: 1,2,5,6
Main: 4,5

We start with a blank repo and an initial commit.

Most designs will be merging production changes into main, so we create a commit that simulates months of hard work as "Perfectly good main branch".

We realize that we should be working on the develop branch, so we change the branch to develop and merge in the changes from main:

checkout develop
merge main

We then make change 1 and push it to dev:

We make change 2 and push it to dev:

At this point, we "accidentally" switch to the main branch without merging and push commit 3:

And then we push commit 4:

We come to our senses and switch back to the development branch to push changes 5&6.

We're happy with our changes and create a new design review (pull request). It's now that we realize the beginnings of our problems. We can't finish the design review because there are merge conflicts.

Before doing anything irreversible, switch to the main branch and make a copy of the files so we can reference them later if we need to copy the changes.

We need to reset the main branch back to the point where it diverged from the development branch. In this case it's the commit labeled "Perfectly good main branch". Afterwards we force push to update the remote repo.

git checkout main
git reset --hard 93a2c469d7 
git push -f

We then go to the design review and merge the changes.

We can see here that we've lost the changes from commits 3 and 4. If we want the changes to be integrated, we'll need to open up the backups we made and copy the changes manually and push new commits to the dev branch.

Your mileage will vary

There is no one-size-fits-all solution to your merge conflicts. It may be that you catch the error in time and you just use git merge to move the changes to the correct branch. It could be that you've made many interwoven changes that you don't want to lose. Resetting and force pushing is a destructive operation and should only be used in small doses when you're aware you're blowing away the existing work.

It can't be stressed enough that a local backup can save a lot of time and energy in case you delete or overwrite the wrong files.

An ounce of prevention is worth a pound of cure, so check the branch you're committing and pushing to often, but when you eventually encounter a merge issue, know that you can reset to a previous location in a branch to have a clean merge.