How can I author changes that are not prone to merge conflicts?

Question

Automated merging isn't perfect. Just because there isn't a line-edit conflict doesn't mean there isn't a syntactic conflict, and that doesn't mean there isn't a semantic conflict.

Does anyone have strategies for authoring low-conflict changes? Is this something that falls out of TDD or other approaches (Certainly TDD will help catch them, but does it actually prevent)?

Answer 1

I've always found that the smaller my commits, the less likely they are to have merge conflicts. The folks who have big problems always seem to go off for days and work on things, then try to merge them all at once.

Right now I'm working on a 2 man team where we are right in the same codebase all the time. We each work in a personal branch and then integrate to a shared branch whenever we have something working. That's usually several times a day. We almost never have merge conflicts, and when we do they're pretty trivial.

So... get the latest code from the repository frequently. Work in your own branch, so you can commit your changes and merge other folks' work without affecting the rest of the team. Then push your own code up to the shared branch as frequently as possible so the changes will be as small as possible.

Also, talk to your team. If you know someone else is working in a specific file, you might want to wait until they get their work in before you jump in. Sometimes you can't help it, but communication at least lets you plan for a complicated merge rather than being surprised.

Answer 2

Classes that violate the single responsiblity principle are the hardest to merge. Finding a class that was difficult to merge probably is a sign that it needs to be refactored, probably in the direction of more parts.