The standard git workflow (and this github feature) seems to promote resolving the conflicts alongside all of the other changes in the merge working copy. This make me nervous, as there's no way to differentiate the new lines that were introduced to resolve merge conflicts from the thousands of lines of (previously reviewed) code from the feature branch.
If you're not careful, completely unrelated working-copy code and behavior can be introduced in a "merge commit" and neither you or any of your reviewers will notice. "Looks good to me."
On the other hand, with your approach you are going to have revisions that won't even build/compile.
If you have automatic builds or/and unit/integration tests, then you'll have failed builds every time you have a merge conflict.
Also, you are kind of 'polluting a well': what if meanwhile someone merges that revision into his/her branch? Or what if you have automatic merges configured?
It can be a bit noisier at first but once you learn to read it, I find it makes resolving conflicts so much easier.
For those of you who haven't used it, try switching it on and/or read https://psung.blogspot.com.au/2011/02/reducing-merge-headach... for more details.
tl;dr it shows
FYI: If anyone is interested in the section about git rerere (reuse recorded resolution), the link at the bottom of that article leads to a 503; a repost can be found here: https://git-scm.com/2010/03/08/rerere.html
But not everyone is working on big projects with tests, and not every merge conflict is actually complex code modification.
Sometimes it's just two commits adding something at the end of the file and there's not real conflict, or maybe you modified the same line twice and forgot to pull before doing your 2nd edit.
