How to revert a few commits in Git without creating reverse patches?

Question

Consider the following situation.

There is a project X with some active upstream development. We are working on a fork of project X for our own internal purposes. Since we do not have write access to the Git repo of project X, we created our own clone of that Git repository on our own server. All co-workers use that cloned repository as origin when working on their local machines.

In order to be able to continuously integrate project X's upstream development into our fork, we do not touch the master branch on our origin server. (The master branch is set up to track the master branch of the Git repo of project X.) Instead we work on a branch my_master where we commit our changes (and push them to the origin server). On our origin server, we can then regularly pull the newest commits of project X into the master branch. Then, we can switch to the my_master branch and merge in the newest developments of project X into our own fork by running git merge master.

Good. However, now a co-worker working on our fork accidentally makes a lot of commits on the master branch instead of doing them on the my_master branch, and pushes these to the origin server. He notes his mistake, locally switches to my_master and merges his master branch into his my_master branch so that these changes exist on the correct branch, and pushes that also.

So the my_master branch is fine now, but the master branch contains some patches that should not be there. Of course, we could revert these changes by creating "revert commits" that revert the individual commits that were wrongly made. Then the state of the master branch on our origin server would again look like the state of the master branch on the Git repo of project X. However, it actually contains some revert commits. This means that, the next time we update the master branch on our origin server, and try to merge the upstream changes into our my_master branch, the revert commits will be applied also, and the new features that were supposed to be built into the my_master branch will be undone. Is this correct?

So how can we do it? In principle we would like to reset the master branch on the origin server to the commit at the point before the unintended commits were made. But we cannot create a revert commit because this would mean that the next merging of master into my_master would revert the changes on the my_master branch also.

Answer 1

First of all, I would suggest you revert the reverted commits in the my_master branch to keep a linear history in the master branch. This way is the safer way, although this way they will still all show up into the commit history.

If you really want those commits to disappear, the other way around that is to do a rebase interactive in the master to remove them, but then everybody will have to rebase their branches that was based on that faulty master!

git rebase --interactive [commit hash before faulty commits]^

(Do not forget the ^ after the commit hash)

It will open your default text editor, and all you will have to do is delete the lines of the faulty commits.

That way it will be like they never happened. But be careful to get them back into the my_master branch (after being rebased against master) by using cherry-pick. Then push --force origin master, and ask everybody to refresh their remote, and rebase their work against the rewritten master.