How do you organise a team's work so that merge conflicts stay rare?

## Conflict rate is a function of two variables A conflict needs two conditions: the same region changed on both sides, and enough time apart for both changes to be made independently. That gives two levers, and both are under a team's control: - **Divergence time.** The longer a line lives away from the shared one, the more of everybody else's work it has not seen. Risk grows worse than linearly, because a long-lived line also accumulates more surface of its own. - **Touched surface.** A change that edits three files can only collide in three files. A change that reorganises forty can collide in forty, and each collision is harder to resolve because the resolver has to reconstruct a large intent from a small region. Everything else on this list is a way of pushing one of those two down. ## The levers | Cause of frequent conflicts | Lever | |---|---| | lines live for weeks | integrate small changes into the shared line daily; take the shared line back just as often | | one change carries several concerns | split by concern so each change touches a narrow surface | | everyone edits everything | clear ownership per module, with an agreed interface at the seam | | formatting disagreements | one agreed format applied mechanically to the whole codebase, checked automatically | | generated or compiled output tracked | keep it out; rebuild it instead | | a large mechanical rewrite in flight | land it alone and fast, announced, with no behaviour change inside it | Note what is *not* on that list: choosing a cleverer merge tool. Tooling helps you resolve a conflict; it does not change how often two people edit the same region. ## Formatting and generated content are self-inflicted Two of the most common sources of conflict carry no information at all. Whitespace, wrapping and ordering disagreements conflict as loudly as real logic changes, and resolving them teaches nobody anything — so the decision should be made once, applied by a tool to everything, and enforced automatically rather than argued per change. Generated output is the same story with worse odds: it is derived, it changes wholesale, and it conflicts on every regeneration. Rebuild it rather than tracking it. The general principle is worth stating in an interview: **any conflict whose resolution requires no judgement should be designed out of existence, not resolved faster.** ## When two groups keep colliding Repeated conflicts in one region are structural feedback, not bad luck. Consider a university admissions system where the home team and a second team in another timezone both work inside the applicant-scoring module. With almost no working-hour overlap, every collision costs a full day of round-trip, and a 31-column applicant record edited from both sides produces the same conflicted region 4 or 5 times a month. Resolving faster does not help; the options that do are: 1. **Split ownership along a real seam.** Define the interface between the two responsibilities and give each team its own side of it. This is a design change, and that is the point. 2. **Sequence explicitly.** When both must change the same region, agree who goes first and have the other take the result before starting, rather than working in parallel and reconciling afterwards. 3. **Shorten the loop across the timezone gap.** Integrate before handing off at the end of each side's day, so the largest divergence window is one working day rather than a weekend. Exclusive locking of files is the instinctive fourth option and is usually the wrong one: it converts a conflict into a queue, and a queue across timezones is more expensive than a resolution. ## Landing a mechanical change without a week of pain Sometimes a sweeping change is genuinely required. Make it a change that touches many files and changes no behaviour, land it on its own, and land it quickly; announce a window so others integrate immediately before and after; and never mix a behaviour change into it, because the reviewer's only defence is that the transformation is mechanically verifiable. The opposite — a long-lived line carrying both a rewrite and new features — is the single most reliable way to generate weeks of conflicts. ## What good looks like A team in this shape rarely discusses conflicts at all, and the ones they do get are informative: two people genuinely changed the same logic, and the conversation about which intent survives is worth having. If your resolutions are mostly whitespace, regenerated files, or the same region every week, the fix is not better resolution technique — it is a change to how the work is cut up.