Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble...
I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!)
Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out...
The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...
I do agree though that my first step would have been merge from master to the topic, or rebase the topic onto master.
Presumably if you're merging a bunch of other changes in anyway, you're going to need to do a bunch of testing in any case, that's just an inevitable result of splitting the deployment into two phases.
In most real situations you'll probably find that only a small number of commits actually need to be reverted and reapplied, especially if your team is good about having reasonably self-contained commits.
If you're concerned about filling the git logs up with noise, you can always do use rebase to combine any revert/re-revert commits into single log entries.
For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy.
I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it.
While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing.
EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.