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 revert that merge because it isn't ready for deployment to our production servers.

However, if a developer attempts to issue a Pull Request again, it does not recognize these changes were reverted and sees that the commits are already in the master branch. It only will include their recent commits since the revert, but what we really want is to reintroduce ALL of the commits there were reverted, plus their new work. In other words, we like a way to reissue the original Pull Request.

Since Github doesn't support this feature (i.e., neither reverting a merge, nor undoing/reissuing an original pull request), I am currently reverting the reverted merge. This feels wrong.

What other ways could I use to achieve the same goal in git? (or Github if it's possible)

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.

Answer 2

I would suggest you guys take a different approach. Your workflow of reverting and reverting reverts seems very confusing to me. The actual problem you are trying to solve can be tackled differently.

I suggest you change your workflow to use two branches. One stable branch (master) and one development branch (develop). All work goes into the develop branch, or into separate topic branches. Pull requests are always filed against the develop branch, then merged into develop when approved.

master is initially branched off of develop. As soon as develop is in a stable state, you merge it into master. master is the current stable release.

This is loosely based on nvie's "A successful Git branching model".

Answer 3

If you get a branch-per-feature regiment going, you can rebuild a release candidate with what features you like. You will not need to "revert a merge":

further reading: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Please see the comments as well for additional insight. It works really well for us.