Has anyone faced this situation with contributors before? Is there a reliable 30 min guide for how to use branches and PRs for someone who is "just not getting it" so far?
https://imgur.com/a/xNu8RLr
#1. Insist on hunked, with appropriate commit messsage, commits for their PR - can simplify code review
#2. Use git rebase from master to their branch - where they fix any merge conflicts - before submitting PR
#3. Make use of git commit --amend for updates that dont need to leave a trail of noise while working towards #1 - you still have all that noise in the reflog if you really need it
#4. Ensure git rebase --i is used to ensure no commit history noise prior to their PR
#5. Any formatting amendments should be done pre/post PR
#6. Use pre-receive hooks to block PR and reduce any unnecessary forgetfulness of the above points
At the end of the day, they should be following a sane set of coding standards that the project has outlined - which everyone should adhere to, but also be involved with setting, and then following.
There are plenty of coding standards out there, find one that fits your project best, and modify accordingly - be sure create a repo that provides guidance to the standard and keep it up to date.
You could start by not doing this and instead working your way together to fixing the problems because that's literally what PR's were made for, even more so on GitHub where unlike in email, you can discuss it in almost real time. It looks like you have as much to learn as him, because even if you have to make 500 commits to fix all issues, there's this git feature called commit squashing that helps you clean things up even after the fact, and branches, especially personal ones, can easily have their whole history overwritten without fear as many times as you need it.