Your old workflow was fine because nothing broke

Git is confusing and your old SVN workflow was simple, and you’re not doing anything wrong. That’s just how git works.

The comparison is worth pulling apart though, because a lot of it rests on an assumption you might not have noticed making. You’re taking the old setup as fine partly because it was straightforward and mostly because nothing catastrophic ever happened while you were using it. Those are different claims. The second one is luck reported as design.

Ask what would have happened if the SVN server had died. You’d have had a very bad time. Everybody would have downed tools until it came back, which on a large project is an expensive morning and possibly several. It isn’t an unrecoverable disaster and it is a shape of problem that git simply doesn’t have, because everyone already has the whole thing and you can stand up a new remote while people carry on working locally.

That’s the assumption baked into git that makes it feel over-engineered until the day it isn’t, and one day all of this is going to go horribly wrong. The tool is built by people who took that seriously, and the cost of taking it seriously is a mental model that’s harder to hold, which you pay for every single day in exchange for a bad day you might never have.

There’s a second assumption in there worth naming. Git treats the code as important in itself rather than only as a means to a working deployment. It isn’t just whether the thing runs. It’s whether the change is something the team has looked at and agrees with. Pull requests exist to give people visibility of how the codebase is moving and a way to have an input before it lands, which is a workflow decision rather than a technical one.

If your old process was that a feature did what it needed and UAT nodded it through, then there was very little oversight of what went to production. That can work well. It requires a solid UAT process and developers who genuinely care about the code they write, and where you have both of those you can go a long way without much ceremony. Where you don’t have both, the ceremony is doing something you weren’t seeing.

The branching model points the same way. Pulling the base branch into your local one and resolving conflicts on your own machine means the base branch should always work and always be deployable. With SVN it’s easy to break something and block everybody else while you sort it out, and the fact that this happened rarely doesn’t mean the exposure wasn’t there the whole time.

None of that makes git well designed as an interface, and the complaints about it are mostly fair. It’s just that a simpler tool feels simpler in the ordinary case and the difference between the two shows up in the cases you haven’t had yet.

That’s the honest comparison. Not simple against complicated, but which failures you’ve decided to buy insurance against, and whether the premium is worth it for the size of team and the length of project you’re actually running.

The general shape of this comes up whenever anyone compares a tool they know well to one they’re being made to learn. The familiar thing has failure modes you’ve internalised so thoroughly that you no longer count them as failures, and the new thing has failure modes you hit on the first afternoon and remember vividly. That asymmetry is real and it isn’t a reason to stay, and it also isn’t nothing.

What it means is that the comparison is worth doing on paper rather than from memory, because memory is systematically kind to whatever you already survived.