Every new Visual Studio release improves the Git experience, and every time it does, someone on a team suggests the improved tooling will fix how the team works with Git.
It won't, and I say that as someone who likes good tooling. The problems teams have with version control are almost never tool problems. They're agreement problems, and a better client makes a bad agreement faster to execute.
The Only Branching Question That Matters
There's an enormous amount written comparing branching strategies. Most of it is beside the point, because the real variable is simpler: how long does a branch live before it merges?
A branch open for a day is nearly free. It merges cleanly, it's reviewable in one sitting, and the person who wrote it still remembers why.
A branch open for three weeks is a liability regardless of which strategy's name you've given it. It has drifted from main, it will conflict, its review will be a rubber stamp because nobody can hold 2,000 changed lines in their head, and the author has forgotten their own reasoning for half of it.
So the question isn't which branching model. It's what's preventing branches from merging quickly — and the answer is usually one of:
- Review latency. A PR waiting two days for a first look teaches people to batch more into each one, which makes the next review slower. It compounds in the wrong direction.
- Work sliced too large. If a feature can't be broken into shippable increments, that's a design problem showing up as a Git problem.
- No way to merge unfinished work safely. Without feature flags, "done" means "completely done", so branches must live until then.
Fix those and most branching debates evaporate. Leave them and no strategy will save you.
Review Size Is the Highest-Leverage Lever
If I could change one thing about how most teams use version control, it would be the size of the average pull request.
There's a well-known and unforgiving curve here: review quality collapses as diff size grows. A 50-line change gets genuine scrutiny. A 500-line change gets comments on the first two files. A 2,000-line change gets "LGTM" and a rubber stamp, and everyone involved privately knows it.
This means large PRs are not merely slower to review — they're effectively unreviewed. You're carrying the cost of the process and getting none of the benefit.
Practical things that shrink them:
- Separate refactoring from behaviour change. A PR that moves code and changes what it does is the hardest kind to review, because the reviewer can't tell which diff lines are which. Two PRs, each trivially reviewable.
- Merge scaffolding early, behind a flag, before it does anything interesting.
- Treat "this is too big to review properly" as valid grounds to send something back. That has to be culturally acceptable or it won't happen.
Merge or Rebase: Pick One, Stop Arguing
Both work. The cost of the debate exceeds the difference between the answers.
What actually matters is that the history is legible enough for the one thing you'll genuinely need it for: finding out when a behaviour changed and why. If someone running git bisect in six months can land on a commit that builds, runs, and has a message explaining itself, your history is good enough.
That gives you two rules worth enforcing, neither of which is about merge versus rebase:
- Every commit on the main branch should build. Otherwise bisect is useless exactly when you need it.
- Commit messages should say why, not what. The diff already says what. "Fix bug" tells a future reader nothing; "reject claims with future service dates — payer rejects these downstream and the error was surfacing three days later" tells them everything.
What Tooling Genuinely Helps With
Having argued that tools don't fix process, let me be fair about where they do help.
Good integrated diff and conflict-resolution UI removes real friction, and friction is why people postpone merging. Seeing your branch's relationship to main at a glance makes drift visible before it's painful. Fast blame and history navigation turns archaeology from a chore into something people actually do — which matters, because understanding why code is the way it is prevents a lot of bad changes.
So: adopt the better tooling. Just don't expect it to produce small PRs, timely reviews, or clear commit messages. Those come from agreements the team makes and holds each other to, and no client ships them.
The Short Version
Short-lived branches. Small pull requests. Fast reviews. Commits that build and messages that explain themselves. Pick merge or rebase in five minutes and never revisit it.
Everything else is preference, and preference is cheap once the agreements are in place.
