Since the first one inevitably irritated people, let’s go for rule #2 & #3:
2.) Check in as often as you come to a stopping point. The more frequently you check in, the less troubling your merge conflicts will be. For the most part, I think you can make merge conflicts almost entirely go away after the first couple weeks of the project. We had a mild conflict today (that spawned my tongue in cheek remark about checking in first) that was caused by one pair renaming a testing utility method to make it more consistent with our other testing methods, while my pair was still using the existing method name. Both pairs knew it was coming so it was no harm, no foul
3.) Communicate with your team members anytime you think you might be doing something that would cause a merge conflict. Yet one more reason why a colocated team beats a distributed team
4.) Find ways to divide your work into smaller chunks. If you can’t check in new code for days at a time because you aren’t at a clean point, you may have some serious problems with your design.
5.) If you can’t check in your code for a long time ( > 1/2 a day let’s say), be sure to update your version of the source code with the updates from the rest of the team to make your eventual checkin easier
6.) Rotate your build notification sounds.
7.) And in the “do as I say not as I do” category, you might learn how to use a merging tool (then come teach me).
And yes, you can solve the merge conflict problem by going to a pessimistic locking strategy, but I think that causes much more friction than the occasional merge conflict.
…and some other boring things like making sure the build actually succeeds, fixing broken builds immediately, and making sure that the build sets up the development environment and other details you can find in the Check In Dance.
