So, you’ve heard all your hipster friends raving about git. They say it’s the latest and greatest, and you simplymusttry it. What’s the real story here? I’ll tell you.
Speed is overrated
You’ve heard that git changes the way you work; most operations are local and blazing fast, blah blah blah.
Do you really need all this speed, though? How long can it take to carry out ansvn updatein the morning? Five minutes? 10 minutes? Are those minutes really that big of an issue? Switching branches in subversion might take a few minutes, too. But really, if you have more than two branches, you’re doing it wrong.
And please don’t tell me that those few extra seconds you have to wait after each commit or update add up to anything more than just a tiny inconvenience. Get over it.
Who needs local branches?
Cheap local branching –githas them. But why would you needlocalbranches? You’ve been committing to a remotetrunkfor years and everything has been great. Yes, your team meshed everything together: fixes, new features, proof of concepts. All in thetrunk. Sure, sometimes you have to keep uncommitted changes on your machine for days. But if it works, why fix what’s not broken?
“And no, it wasn’t me that broke the billing system. I just fixed a typo in the About page!”How could you possibly know that there is where the main USD/EUR conversion was happening? You work with such amateurs!
The old workflow has worked until now
Workflow innovation? Efficiency? Pssh, nonsense. Processes have finally been grokked. You have your procedures and they just work. They are documented. You might lose your ISO certification if you make radical adjustments to the way your team works.
Trust me – I had to sit in five architectural board meetings to decide whether to switch from Notepad to Word. Word won by one vote.
Centralized is safer
Do you reallyneeda decentralized version control system? Of course not! You have an IT department for a reason – to separate concerns and lower costs.
Let your DevOps people make sure the central repository is backed up. Why would you need the whole history of the project locally? Are you really going to check who did the first commit on the project?
Merges should be avoided anyway
gitis good with merges.gitis good at branches.gitis good at everything. Aren’t you tired of hearing the same thing over and over again?
Let’s be honest: You shouldn’t be merging because you should not have more than one or two branches anyway. A singletrunkin most projects will do! But let’s say you really need branches, maybe a release branch for some very important upcoming release.
Isn’t it easier to have a person – or even better, a team – dedicated to merge code and resolve conflicts? Somebody familiar with the process? They can look at diffs and email the relevant persons in the company on how to resolve them. Again, if it ain’t broken, why are you trying to fix it? Yeah, if your “merge” team is busy, a release might need to be delayed. But that’s normal. All software teams have delays, right?
Don’t let all your developers buy into this craze where you create a feature branch for each tiny bit of work. That creates fear, uncertainty and doubt. FUD. Enough said.
You don’t have time to train your developers
Developers should be cranking code out. You have deadlines and releases to worry about. How can you spare the time to adopt yet another technology that needs planning and resources? Who cares about the benefits? It’s just not worth it.
I was also against moving away fromCVS. Just saying.
- For the few that arrived this far without raging:Yes, this is satire.Your spidey sense wasn’t misfiring.
- For those who did not read to the end and now are mad at me, it’s ok. I knew it would happen.
I’ll end the masquerade:I am agitevangelist!gitis awesome and you should adopt it as fast as you can.
If you want to know more aboutgit, check out our awesomeGit tutorials. And if you are looking for a git repository management tool let me advise you to considerBitbucketin the cloud orStashfor behind the firewall.