Like many devs who’ve been round the block a few times, I got my first professional experience using SVN.
My first exposure to Git was at a place that was using it exactly like it was SVN, with one master branch that all the devs pushed to, and nobody was allowed to push for two days before a scheduled release in case they broke something. They’d switched because they knew Git was the cool thing that everybody raved about, but they got confused by the overly-detailed tutorials and the new jargon and never worked out how to use it to improve their workflow.
I Googled just enough to learn how to get my code into the master branch, understanding about 10% of what I read and liking even less. Why did I want a localised repository? How was this better than SVN when there were more steps required for me to do the “same thing”?
That was seven or eight years ago now. Since then I’ve worked on a huge variety of projects and seen the difference that a well-designed Git workflow can make to a team. I’ve recently dipped my toes back into a project using SVN and it’s helped to clarify the benefits in my mind.
SVN Devs are terrified of branches
Branches sound all fine and dandy until you need to sync things up again, and in SVN-land that usually seems to go to custard. It’s easy to lose half a day swearing at a bad merge … so they don’t. Everything happens on the trunk.
The first ever commit made by a rookie dev that breaks the build. The urgent bug fix for the production environment. Possibly the stuff somebody was in the middle of when they had to stop and do that urgent bug fix. The regular save-points for a major feature which isn’t ready for production yet. The stuff that’s supposed to go into the next release. The stuff that’s finished, but when you demo it to the business they don’t like it and don’t want it in the next release.
This works OK for a very small team, if everyone is communicating well and know what code they are allowed to commit when. It’s easy, and at first glance there’s no overhead.
As the team gets larger, you finish up with an almost constantly broken branch that makes your devs tear their hair out. They start updating as rarely as possible, and when they do there’s usually a mess of merge conflicts.
Comments, Comments Everywhere
It also leads to a proliferation of comment blocks. Old code gets commented out because devs aren’t confident about how to get it back if they need to revert in a hurry later. Recent code gets commented out by other devs because it’s got bugs and they can’t get their work done. New features live in if (false) blocks or comment blocks until they’re ready to go live.
Your team has to scroll through all of this commented-out stuff every time they scan the codebase. And it gradually rusts because the IDE doesn’t pick it up when you’re refactoring, so then when you do decide you need a relic from the past, it often needs resuscitation first anyway.
How Git Can Help
Git is definitely more complex than SVN. The learning curve to understand everything is huge (I’m nowhere near the top) but it’s not that hard to learn enough to manage a simple workflow in Git.
Branching and merging is easier in Git, so your devs will be more inclined to use branches. It’s not that hard to keep your production code separate from the stuff you plan to release next week, and your incomplete features aside in their own branch.
The major Git hosts (e.g. Github, GitLab, Bitbucket) all have sleek user interfaces that make it easy to explore the code base, review code before it’s merged into your main development branch, and travel back in time to see what changes were made when, by who. This helps with the cargo-cult commented-out code clutter – there’s another place to get that code back on the remote chance that you really do need it, and in the meantime it’s not cluttering up the source code.
A transparent code review process that happens before code makes it into the development branch can lead to big improvements in the quality and consistency of the code. Everyone can see the code that’s up for review and what’s been said about it, which helps to keep the common issues at the front of people’s minds. Newcomers can skim over the pull requests to get a quick idea of how things are formatted now (rather than 5 years ago when the class they’re working on was last changed) and to get a quick overview of how a new feature is put together.
There’s always going to be some disruption when you switch to something new, but the gains in long-term productivity mean that the change will quickly pay for itself.