the git command-line interface is... not exactly easy to learn.
I dispute the accuracy of your opinion. example follows...
From the article: you should never ever use the github interfaces to merge anything
When I read that part, I knew EXACTLY why Linus would say this. For a raw pull request (i.e. submitting your dev branch's differences from the official repo) the github inteface works very well. For actual editing and stuff, no.
Therefore you should just do all of your merges and any additional edits using a decent local merge tool (maybe 'meld'?) between your local working copy and the dev branch on github, after you do a 'git pull' on your local copy of the dev branch so you know that what you're comparing to for your merge is at least CLOSE to what you'll be doing the pull request for (assuming that no major edits in the official branch affect the pull request).
Then use 'git commit' followed by 'git push' to your dev branch, and then do the pull request.
You really only need to memorize and master a few git commands:
git status
git pull
git push
git commit
git add
git rm
the rest of the commands can be looked up in the docs "whenever", as needed.
NOT that hard. seriously NOT. But yeah you need a token. And I solved that.
If you search for it on github, I wrote a simple program that lets you use a pass phrase to decrypt an encrypted file and put its contents in the clipboard (for X11 systems though). In short, you would encrypt the github issued 'password' token in a file, and then run the utility from a command shell (say 'bash') and enter your pass phrase, and the github token will be on the clipboard. Then, when you do 'git push' and git prompts for user/pass, you type in the user and paste the token when it prompts for password. This is due to github's recent policy change regarding pass phrases and git command line, and the method I use can be put on computers you do not own (like customer machines) as needed to access github repos without revealing your token.