Question

I’ve gotten myself into quite a tangle.

I committed a restructuring change that significantly reduced functionality to master. (I recognise that this was a mistake.)

This started to cause problems, because it was unfeasible to use the program with that change applied, but I had already committed further, unrelated improvements to master.

So, I reverted the restructuring change on master, and started a new branch (say restructure) based off the commit before the revert.

The problem now is that further valuable commits have since been made to master that I would like to pull in to restructure to ease its development. But git merge tries to apply the revert of the initial restructuring — oops!

I’m not sure what to do now, and I feel like a bad decision now could vastly complicate the merge back in to master later on.

To complicate things further, the restructure branch has been pushed. However, I don’t mind having to use git push --force if it’ll clear up all this mess; only a few people have pulled the repository since.

I accept that the true solution to this may fail to be an answer to the question asked — this definitely feels like an XY Problem scenario — but I had to put something in the title 🙂

Note: I realise all this is symptomatic of a bad git workflow, and this is certainly incentive enough for me to do things more properly in the future. However, I can’t retroactively not have done the wrong thing, so my problem remains 🙂

Answer 1

Since you have not pushed master (?) and even if you have are also ok to force push and rewrite the history, you can just git rebase -i in master and remove the restructuring commit itself rather than reverting and then create the restructure branch from master itself ( since you are going to merge anyway) and work on it.