Your plan is largely sound.
Source Control:
Make it mandatory for the developer's job. By all means, send that developer to training or a local dev group for a beatdown. Convince your mutual boss of the need. (If you have to, use the 'turned malicious' or 'left something out' scenarios, or the plain-simple 'webserver got hacked and defaced' scenario. Although I would recommend git for any new projects, hosted on either a private server or a paid-for github account. ThinkLikeAGit, Roger Dudler's "Git - The Simple Guide", and "Git for Ages 4 and Up (direct to video) are all awesome.
I prefer that Master be a main development branch, a Staging Branch to be deployed for testing, and a Production branch (or Tags on the Staging branch with version numbers on the deployed commits). I also like the idea of branches for features. Ask 100 developers how they like their source-control, and you'll get about 65 answers...
I strongly dislike and advise against Master being the "Production" branch. One newbie mistake (which EVERYONE makes) is committing to the wrong branch. Don't let Production be the default branch.
Development Server:
Yes, a place for the dev to go crazy. Do whatever you want; this is your home, sandbox, whatever. Development should happen at the local machine, but this is an environment that will look like production, but the flexibility to go crazy. VM with snapshots taken at the base-state (and whenever Prod gets updated) are recommended.
Staging Server:
Once the dev is happy with her code, it gets deployed to the Staging Server. This is a server that exactly matches production with the exception of the URL. (Her code should be using relative paths, and not the site's actual name.)
Here's the kicker: Once she's satisfied that the site is ready for Production, she stops. She doesn't deploy to Prod (yet.) A Hither-to-unknown QA process now happens. Somebody with an eye for mistakes (and who has at least an overview understanding of what this new code should be doing) reviews the site in Staging. (You, the creator, are blind to many of your own mistakes, making you unqualified to validate your own work.) They test the site, ensuring that the problems that are being fixed, and that nothing new is broken.
I cannot stress this enough: The Developer does not do QA! She should ensure that her site doesn't have any obvious brokenness before passing it to QA, but she does not approve it for Production. (First, she has demonstrated a lack of understanding of best-practices, and mistakes have shown that best-practices exist for valid reasons.)
The person who is doing QA has their professional reputation at stake; If a mistake is pushed to Prod, it's their approval that made it happen.
If QA finds mistakes, they are identified to the developer to fix. The process beings anew, complete with QA review and sign-off.
Personally I'm a fan of Devs doing their own deploys. They get the instant feedback of knowing that the task is completed, and by not making someone else do the deploy, they feel a greater sense of ownership if something goes wrong. (Saying "it works on my machine" should be a capital offense.)
The most important part is that what is in the repo gets deployed. There are no 'one-off' cowboy-coding changes.
Production:
Once the QA sign-off has happened, the code can finally be pushed to Prod. It's up to you and your org who does the deploy; it can be the coder or it can be the QA person. If the deploy doesn't execute completely, it goes back to the developer.
In Conclusion:
The way things are going now obviously doesn't work. Push to make something like this mandatory company policy (if you agree with it, of course), and make employment conditional on it's adherence. It may make more steps for your poor developer, but for the company it's less work, especially in having mistakes go live. Not to mention the safety net of having known-good states of your code that live outside of the Production webserver.
Optional Bonus Points
I don't know what you're doing for deploys, but they should be one-step or no-steps.
An example of a One-Step Deploy is a script that you run on or against the Prod server (and should be the Staging servers as well, and Devl, too) that pull down the appropriate Branch from your repo and restart the needed web services.
An example of a No-Step Deploy is a cron that watches the appropriate Branch and automatically updates the code when the Branch is updated.
