I can think of some “programming best practices” that can help with reducing merge conflicts, such as making small functions/methods, but I see it as a positive side effect.
I don’t think avoiding merge conflicts should be a goal we actively try to reach. Writing readable code organized in atomic commits will already help you get fewer conflicts and will make them easier to resolve.
I’ve seen too many junior and students being distracted from getting their task done because they spent so much time “coordinating” on order to avoid these “scary” merge conflicts
No, not like that – you misunderstand. I’m not talking about actively avoiding conflicts. Coordinating to avoid merge conflicts is the same work as resolving a merge conflict anyway, just at a different time.
I’m talking about creating practices and environments where they’re less likely to happen in the first place, never incurring the coordination cost at all.
One example at the individual level is similar to what you mentioned, but there’s more to it. E.g. atomically renaming and moving in separate commits, so git’s engine better understands how the code has changed over time and can better resolve merges without conflict.
But there’re other levels to it, too. A higher-order example could be a hot module where conflicts frequently occur. Sure, atomic commits and all that can help “recover” from conflict more easily, but perhaps if the hot module were re-designed so that interface boundaries aligned with the domains of changes that keep conflicting, future changes would simply not conflict anymore.
IMO the latter has an actual productivity benefit for teams/orgs. Some portion of devs just aren’t going to be that git proficient, and in this case, good high level organization is saving them from losing hours to incorrect conflict resolutions that can cause lost work, unintended logical conflicts (even though not lexical conflict), etc. Plus, it implies abstraction boundaries better match the changes demanded by the domain, so the code is likely easier to understand, too.
I can think of some “programming best practices” that can help with reducing merge conflicts, such as making small functions/methods, but I see it as a positive side effect.
I don’t think avoiding merge conflicts should be a goal we actively try to reach. Writing readable code organized in atomic commits will already help you get fewer conflicts and will make them easier to resolve.
I’ve seen too many junior and students being distracted from getting their task done because they spent so much time “coordinating” on order to avoid these “scary” merge conflicts
No, not like that – you misunderstand. I’m not talking about actively avoiding conflicts. Coordinating to avoid merge conflicts is the same work as resolving a merge conflict anyway, just at a different time.
I’m talking about creating practices and environments where they’re less likely to happen in the first place, never incurring the coordination cost at all.
One example at the individual level is similar to what you mentioned, but there’s more to it. E.g. atomically renaming and moving in separate commits, so git’s engine better understands how the code has changed over time and can better resolve merges without conflict.
But there’re other levels to it, too. A higher-order example could be a hot module where conflicts frequently occur. Sure, atomic commits and all that can help “recover” from conflict more easily, but perhaps if the hot module were re-designed so that interface boundaries aligned with the domains of changes that keep conflicting, future changes would simply not conflict anymore.
IMO the latter has an actual productivity benefit for teams/orgs. Some portion of devs just aren’t going to be that git proficient, and in this case, good high level organization is saving them from losing hours to incorrect conflict resolutions that can cause lost work, unintended logical conflicts (even though not lexical conflict), etc. Plus, it implies abstraction boundaries better match the changes demanded by the domain, so the code is likely easier to understand, too.