But to answer the question, the best open source projects I have worked with have had peer review, someone else on the project is the one who actually pushes your code into the repo, this works a great sanity test and catches most of the common implications that you may have missed, but another good part of this is that it works as lazy concencus now all the people who may have issues with your patch have the opportunity to discuss it before it lands while at the same time not adding too much overhead and bureaucracy to get code landed.
The other thing is that the code (or individual parts) have to have owners who have the final say in any disagreements, its impossible to get everyone to agree on every change and sometimes an owner just needs to come in and make a final decision, open source that attempts to work as a democracy has a very hard time in my experience.
You don't go handing the keys over to the main repository to just anyone. You make contributors fork your work, then you pull in changes that you like. This leaves you 100% in control of versioning and the main branch of the project.
If you're not project lead, you don't.
Something along similar lines came up on Ars Technica a little while back "How should I behave as a developer in a project that’s headed for failure?": http://arstechnica.com/information-technology/2013/07/how-sh...
There are some good ideas there to better engage something like this.
Any other developer who's having problems should go through the leadership first or has no alternative but to leave. It sucks to swallow your pride, but taking matters into your own hands (as some of the comments on the SO post suggest) can lead to anarchy. Then everyone loses.
Brian Fitzpatrick and Ben Collins-Sussman from Google have done a bunch of great talks about exactly this: How Open Source Projects Survive Poisonous People (http://www.youtube.com/watch?v=Q52kFL8zVoM)
They also wrote a book about the topic: http://shop.oreilly.com/product/0636920018025.do
All of their advice comes from their experience running the subversion project. It is also good general advice for dealing with humans/engineers/etc.
If you have personal issues with the programmer, such as their attitude or behavior, bring them up in a personal setting with the programmer himself.
Your issues regarding the way decisions are made within the project should be raised with the leadership.
If you don't communicate your issues to the responsible parties then you can't expect them to change.