You know the feeling. You’ve just spent four hours untangling a merge conflict that shouldn’t exist. Your team’s branching strategy looked beautiful on the whiteboard — feature branches, release branches, hotfix branches, all flowing like a river. But in practice, it’s a swamp. And you’re the one wading through it.
This isn’t about Git. Git is a tool. The problem is what we’ve turned it into: a crutch for avoiding the one thing that actually works — direct human conversation.
Pull requests are not a collaboration tool. They’re a bureaucratic monument to our fear of talking to each other.
I’ve seen it at every company I’ve worked at. A team of six engineers, all sitting in the same Slack channel, but they’ll spend three days waiting for a code review instead of walking over to the next desk and saying, ‘Hey, can you look at this for five minutes?’ The PR replaces the conversation. But a PR is a slow, asynchronous, context-free document. A conversation is synchronous, rich, and fast.
Let’s be honest: the branching strategy itself is often a symptom of deeper dysfunction. You don’t need five types of branches to manage a team of ten. You need five types of branches when you’ve stopped trusting your team to communicate. When you need to enforce a process because nobody knows what anyone else is working on.
I remember a story from the Daily WTF — a team that had a ‘release branch’ that was supposed to be merged only after a ‘release candidate’ branch was blessed. But the release candidate branch was never blessed because the lead developer kept forgetting to run the tests. So they created a ‘pre-release’ branch. Then a ‘pre-release-candidate’ branch. The graph looked like a plate of spaghetti. And the worst part? Everyone knew it was broken, but they kept adding rules instead of fixing the root cause: the lead developer was a bottleneck because he refused to talk to anyone.
Complexity is not sophistication. It’s a sign that you’re avoiding the hard part — actual human coordination.
The provocative angle here is that the modern pull request isn’t a technical mechanism for merging code. It’s an organizational crutch used to avoid direct, synchronous communication. We’ve automated the wrong thing. We automated the merge process, but we forgot to automate the alignment process. And alignment can’t be automated — it has to be built through trust, clear ownership, and the willingness to have awkward conversations.
So what’s the fix? It’s not a new tool. It’s not a better branching strategy. It’s a cultural shift. Start by asking yourself: ‘If I had to explain this change to the team in two minutes, face to face, would I still need this PR?’ If the answer is no, then you’re using PRs as a shield. And shields are great for defense, but they’re terrible for building things together.
The best branching strategy is the one that requires the least amount of process to maintain — because the real work is in the conversations, not the commits.
Before you build your next golden tree of branches, ask yourself: are you designing a system that helps your team communicate, or one that helps them avoid it? Because the latter produces a lot of code, but it rarely produces good software.
FAQ
Q: Isn't a pull request still necessary for asynchronous teams in different time zones?
A: Absolutely — for truly asynchronous work, PRs are a godsend. But most teams claiming 'asynchronous' are actually all in the same time zone, just avoiding real-time interaction. The PR becomes a safety blanket, not a necessity.
Q: So are you saying we should stop using pull requests entirely?
A: No. Use them as a final check, not as the primary review mechanism. The key is to reduce the friction: have a quick conversation before the PR, keep branches short-lived, and treat the PR as a record of agreement, not a discovery process.
Q: Isn't the real problem just bad developers who don't know how to merge?
A: That's a convenient scapegoat. The real problem is systemic: when a process is so convoluted that only the 'experts' can navigate it, you've created a bottleneck. The goal should be to make merging so simple that anyone can do it — and that requires good communication habits, not more rules.