Reverting a git merge commit, then reverting the revert

Question

Our team uses Github Pull Requests to manage our workflow, much like what is described here. Upon manually reviewing the accepted Pull Request, we occasionally need to reve

Answer 1

I think that your problem here arises because when you are dealing with the pull requests, you're choosing to automatically merge them on GitHub. Out of the three suggested ways of dealing with pull requests described in the documentation you're using the last one ("Auto Merge"), which was only recently implemented. Personally, I think this is only appropriate for trivial pull requests which are obviously correct. For anything more complex, I would want to use the first approach, i.e.

• adding the requester's repository as a new remote
• fetching from that remote
• trying the merge
• testing carefully
• pushing the result if you're happy

That means that the merged version is only public once you've tested it and decided to push. If you don't want to, you can just reset your master branch to its previous position.

---

As a matter of interest, it might be worth saying more about what happens if you do end up having to revert a regrettable merge, but still want to have the option to re-merge a later version of that branch. Although it might feel wrong, as I understand it the easiest way to deal with that situation is indeed to revert the revert. You can find more discussion of this issue in this post from the Pro Git blog and another discussion of the same problem by Linux Torvalds that might also be helpful.