You will probably want to get a dev server, and preferably a staging environment too. Nobody should ever be pushing from local to production except for their own personal website. Your deploy process should only support dev->staging->prod. You probably want someone responsible for signing off new releases - depending on the organisation, this can be a project lead, a dedicated QA or a duty that rotates each week (with a tangible reminder e.g. only the person with the fluffy toy that week gets to push). However, discuss it with your team first to get buy-in (see below).
I want this behavior to be punished in some way or make it unpleasant as much as possible.
You could have your test suite (you've got one of those, right?) include a check that determines if you are on a production server and, if it does, sends everyone in the office an email saying
Looks like $username is testing on prod, watch out. Perhaps publicly shaming your colleague would be unpleasant. Or your could create technical restrictions like IP-banning your team from looking at prod (which you can lift but you have to justify).
I don't recommend it, though, you would look like the problem, not the person who is testing on prod and you could make yourself very unpopular with the people in the team who don't care.
Surely what you really want is not for this behaviour to be punished but for it to stop?
I forced them/us to use [...]
It's great that you are advocating workflow improvements, but it sounds like either you don't think much of your colleagues and/or that you don't have their full support. This is likely to result in colleagues half-heatedly interacting with the workflow, doing the minimum needed to get code onto production and not really following the spirit of the workflow, which is going to mean more time spent clearing up. And when you're spending more and more time clearing up the results of inadequate interaction with workflow (because nobody else cares, right?) everyone else will be questioning the workflow itself.
So start with a conversation.
Find out why it's happening (is your colleague's machine not as good for testing? Is your colleague uncertain with feature branches or stuck in an svn mindset where commit and push are the same?), explain why it's a problem for you that untested code goes on dev/staging/prod, and see if you can do something to change why it happens (your colleague will more likely do what you want if you've just made it nicer to test locally than if you've just berated them).
If you can't resolve it and it genuinely comes down to a difference of opinion, schedule a teamwide discussion in your next retrospective meeting, see what your colleagues do and think. Make your case, but listen to the consensus. Maybe your team says it's ok not to test textual fixes locally, and you just have a rule that no big features go onto dev untested. Write down in the meeting and read out what you collectively decide about what is allowed on each of the environments. Set a date in a couple of months to review it, maybe at a retrospective.