It depends on the conflict obviously; they come in multiple flavors.
- The religious argument ("Why do you keep using tabs instead of spaces?!?")
The point to make clear in this case is that, in principle, it doesn't matter which one is right, it's actually far more important that the entire team is using the same approach. Explain that to the minority opinion holder (and make sure to highlight that it's not necessarily the right decision, but also not important enough to draw blood over). The degenerate case of this is, for example, a developer refusing to use source control or submit to code-review. That's a management issue, and I honestly wouldn't know how to resolve it without letting the rogue developer go.
- The personal argument ("I just don't like you")
There really isn't a way to mitigate this. Make it clear to both of them that bickering isn't acceptable, and that their personal grudges need to be checked at the door if they're going to be productive members of the same team (this works whether you're the manager or not; peers can be surprisingly influential if they're sure enough of themselves). If that doesn't work, either try to split them up on the org chart to reduce their professional/physical proximity, or get youself a desk well away from them.
The key difference between this and the other conflict types is that there is likely a correct answer. Typically it's to do with the code one or the other developer owns and how it should work (occasionally, it's a larger architectural argument). The key thing to grasp here is that even though there's a correct answer, you probably don't know it. The best thing you can do is mediate to make sure it's a clean argument, and hope that either side can be convinced. Again, you can do this whether they report to you or not, but if you're a peer, they might go to a manager to re-run the play even if you manage to bring them to a conclusion.