Merge conflicts are a coordination problem, not a git problem

The problem isn't git

When two engineers open PRs that both modify auth-middleware.ts, git will eventually tell one of them there's a conflict. But by then, both engineers have spent hours or days on their changes. One of them now has to reconcile two divergent versions of the same code, understand what the other person was trying to do, and merge it all together without breaking anything.

This isn't a git problem. Git is doing exactly what it's supposed to do. The problem is that nobody told these engineers they were working on the same file before they started.

Why this keeps happening

In a team of 10-15 engineers, it's surprisingly easy for two people to end up in the same file without knowing it. Different tickets, different sprint goals, different Slack threads — but the same service, the same module, the same critical path. The engineers aren't being careless. They're just working in parallel on a shared codebase, which is the whole point of version control.

The information that would prevent the conflict already exists. GitHub knows which files each PR touches. It just doesn't compare them against each other. Linear knows which tickets are in progress. It doesn't know which files they affect. The cross-tool correlation that would catch this early doesn't happen automatically.

Early detection changes the outcome

If you know two PRs are touching the same files on the same day — before either one merges — the resolution is a five-minute Slack conversation. "Hey, we're both in auth-middleware. Want to sync up before one of us merges?" That's it. No conflict resolution, no merge headaches, no lost work.

The window for easy resolution is narrow. On day one of overlap, it's a conversation. On day five, it's a merge conflict that takes an hour. On day ten, it might require one engineer to rewrite their implementation against the other's merged changes. The cost of late detection scales exponentially.

This is what Gary does: he watches every open PR, compares the file paths, and sends a Slack message the moment two PRs touch overlapping files. "I might be overreacting, but these two PRs are both touching auth-middleware — might be intentional, just wanted to check." Most of the time it's fine. The times it's not, you just saved someone a day of merge conflict hell.

Coordination scales worse than code

As teams adopt AI coding tools, PR volume is increasing. More PRs means more potential for file overlap. The coordination problem gets worse even as the coding problem gets easier. Five engineers producing two PRs each per week means 10 PRs. The same five engineers using AI coding tools might produce 15-20 PRs per week. The probability of file overlap roughly doubles.

Dashboards that show you aggregate conflict rates are interesting but not actionable in the moment. What teams need is real-time overlap detection: "right now, these two PRs touch the same files." That's a coordination problem, and it needs a coordinator — not a chart.