Should you have pushed a branch instead of merging to master?
That's a good question. If the commit was highly experimental, then pushing a branch probably would have been better. Otherwise, if you had a high confidence in the commit, then merging to master was correct. No need to pollute your workspaces with remote branches if you don't have to.
Let's assume you want to switch this commit to a branch and push it remotely. I'll draw a commit graph for this scenario:
A-C-D
\ \
B---E < master, your_branch
Let's say master was at B, and C & D where made on your_branch. E is the merge commit for the two. On to your questions. You revert master on GitHub & QA by fixing your local repository, and then forcing GitHub in particular to match it. So actually your questions are best answered in reverse order.
First we fix your_branch
git checkout your_branch
git reset --hard D
This will move branch to D, yielding:
A-C-D < your_branch
\ \
B---E < master
Now we fix your local development master
git checkout master
git reset --hard B
Which gives:
A-C-D < your_branch
\
B < master
Good-bye, unwanted merge commit E.
Fix GitHub (and QA)
git checkout master
git push -f
This will force master on GitHub back to B. If you were collaborating with other devs, they would hate for this as you're re-writing history. But since this presumably your personal repository without collaboration, go for it. Now to make a remote branch:
git checkout your_branch
git push origin your_branch
Now that GitHub has been fixed to match development, updating QA should be a simple:
git checkout master
git pull
git reset --hard origin/master # I'm assuming master will be on an orphaned commit after the pull