Everybody keeps telling you that Git is better than Subversion. You keep hearing Git has better workflows, offline capabilities and is faster. But should we really jump on every new technology that is coming around the corner? Your source code is the heart of your software developement and you want to store it with a tool that is working. Here are 6 reasons why you shouldn’t use Git at work.
1 – Git destroys the idea of Continuous Integration
Git encourages you to use branches for your development. But when you work for 1 or 2 days on your branch, you’re not continuously integrate your code changes with those from your co-workers. You don’t know if someone changed something important in between that collide with your changes. And if you want to have your build server automatically build your development branch you need to copy the project for each new feature branch.
2 – Developers can be offended
SVN has this great feature that if you merge a branch to the trunk you lose all commits of the branch. This is great because the developer that has merged the changes is the one that is responsible for the changes. The dev manager can not blame you for a bug. Git keeps all the commit information from a branch when merging to another branch. You can blame the programmer directly. There is no technical protection for developers anymore.
3 – Git destroys the team experience
With SVN merging a change into the trunk is a real team experience. When you see conflicts you have to talk to the two developers that have changed the same code and find a solution. Because of the fact that merging with Git is different you end up with less conflicts and less possibilities to discuss the code changes directly with co-workers.
4 – Developers have too many options
With Subversion you have a simple workflow for adding your code to the repository:
1. You merge your local changes with the trunk on your machine.
2. You commit the changes.
I will not mention the second workflow (branching) because there are lot’s of discussions not to use branches in SVN. We have one simple workflow that everybody understands!
Git gives you the opportunity of lot’s of different workflows you can adapt and even combine: Having a Gatekeeper for your main branch, do cherry picking or let everybody pull and push to everybody’s development branch. What a mess!
5 – Git makes people work overtime
Subversion requires a server to search the history, create a branch or commit code changes. Git stores the wholes repository on your hard disk (what a waste of disk space). This makes it possible to work without network connection with the same possibilities as if you are in the office and connected to your SVN-server. It’s the perfect argument for your team lead to ask you to work over the weekend from home to hit the deadline of the current project. Don’t use Git and let this happen!
6 – Git is unsocial
Subversion gives you time to socialize when creating a branch, checkout a branch or even switch beween branches. You get some time to chat with co-workers, go to the kitchen and grap a cup of coffee or to write comments on facebook. Git changes the game for the worse: Due to the fact that you working just on your hard disk to do all this tasks in Git, it is faster and you lose the natural social time. It’s good for your dev-manger but bad for knowing what’s going on.
It is pretty clear that we shouldn’t use Git at work. Why should we change at all? SVN is a mature technology that has been around for more than a decade. There is no reason to change to a just 8 year old repository technology. Let’s face it: It’s great for open source but in a corporate environment offline possibilities and advanced workflows are not so important. We have been working for ages with centralized version control system. Think about the knowledge that is in the SVN community. Some people will be out of jobs if all companies switch to Git.
Don’t let that happen. Don’t use Git!
UPDATE : Did you git it?
Due to the confusion people have whether this article is meant to be funny or sirous: I love Git and I think it helps teams to do a better job. It solves a lot of problems that we have with SVN. Don’t let our children grew up in a world of Centralized Version Control! Just to be sure you realize that this is just a sarcastic blog post. Hope you had some fun reading it!
Sven Peters 
Thank you for pointing out how dangerous new technologies can be. I think that even SVN can be a bitch, so I switched back to CVS. Best is to lock files in the repository, anyway.
Small annotation though: Please correct your “loose” things. If you do not win, you lose. Not just the game but also your confidence. 😉
Thanks, for pointing that spelling mistake out. You’re right, CVS is way simpler than SVN and the better repository technology.
I’d recommend not using any version management at all. You don’t have to struggle with setting up a server (precious time where you could also write code) and it improves team communication a lot.
Diff/Patch – that’s the way to go! Far superior than SVN and CVS 😛
I’d recommend not using a version control system at all. You save precious time in setting up a server. Time in which you can write code instead. And it improves team communication when doing manual merges. It forces the developers to not just blindly merge but look at what the other developers have coded so far. Great for finding bugs.
I seriously hope you are being sarcastic… Because if your not, I’d hate to work with you.
Setting up a repository takes very little time (svn, git, mercurial, cvs… whatever). Learning how to use the system takes a little time… afterwords the benefits far outweight the few hours you spend learning it.
I’ve had more occasions than I’d care to count where a repository has been worth its weight in gold.
Of course it’s sarcasm, as is this article.
Repository, just like internet has no physical weight. That means it’s worth, expressed as “weight in gold”, is nothing
I love it. Great for covering up mistakes. Nobody can ever find out who was the author. But not only SVN consultants also Git, CVS and Perforce consultants would be out of job. It’s a big business!
I used git for a few years in a corporate environent an I’m really shocked that I didn’t realize what a big mistake that was.
Thanks for pointing that out.
Hi,
Now i work with git for about 4 years and only after reading your article and the comments I realized, that using git and even source control at all kills social time between developers.
Well, looking back to the good old days that I already forgot, everything was better…. Was it? Hmm…
Looks like github is ready for the uprising Subversion movement:
https://github.com/blog/626-announcing-svn-support
They knew all along.
I found to git because drupal uses it now for all the contrib modules. and guess what i find it better and easier than bevor. time to step back 🙂
i love this sarcasm article.
I do hope all of this is satire, either that or you are stuck in the sad world of coporation where you are desperately looking for angles to do less work and be unattached. However, git only offers benefits, for the fact you can use git to mimic SVN if you wish. All of the above arguments are silly, which why I hope this was satire.
If you are trying to hide your work, you have other problems, being transparent means you know what you are doing and are confident in your work, and actually spent the time required to get it done properly. We are human, we make mistakes, and it’s much better to know how to solve them them blindly fiddling around.
I strongly suggest evaluating yourself rather than a tool. Because it is nothing more than a tool.
Obviously you should evaluate your sense of humor. 😉
OMG! I fell terrible for using Git now. I’ll never use it again.
For me to have team work and stop blaming each other, lets keep the code files on a shared folder on central server and we (developers) create shortcut to the shared folder from their machines and directly work on the file. In this way the files are always updated! You change anything, immediately it gets reflected at your co-worker machine 🙂 isn’t this great!!! Also we prevent ourselves from wastage of disk space. Why use CSV, SVN, Git, and Tumbla (future of GIT 5 years from now)
You gave me quite a scare there for awhile 🙂
I have to admit… i got a link to this on G+ read it, but all the way, enough to get me all irked up… Then i read the “Update” part, sighed a bit of relief. Warning to all other “READ BETWEEN LINES mmmkay?”
“Subversion gives you time to socialize when creating a branch …” #lol
I found it beautiful and awesome! git is from hell ¬¬
Thanks for reviving the nightmare. A few years back I actually had to work with a dev lead who, when I suggested using git isnstead of svn, pretty much said then what you wrote down now, and was very serious about it. I should’ve known then that there is no way you can win a religious war with a priest, but I came out of that project pretty scarred. I suggest you run as fast as you can when you’re ever in a situation like that.
Someone is forking this right now.
Fun post Sven. I’m surprised you had to clarify that it is a sarcastic post! :-).
Anyway, would you mind if I translate it into Spanish?.
Thanks
Hi Israel, go ahead and spread the word! Just mention me and link to my original post.
I use gmail. You can open a thread and you will always keep trace of every versions. merging? easy! using the diff command. nothing can beat that.
Oh man… Don’t do it… Gladly I read the update on your post, at the end… If I didn’t, I would certainly hate you forever!
Sorry for the short confusion 😉 Please don’t hate me
Funny article but to be honest i do prefer SVN over GIT
not for the reasons you stated though
except the one about too many branches is bad …
funny thing is git is well suited for
DISTRIBUTED TEAMS OF 1 person…
Git is to me a perfect example of a GOOD IDEA
followed bi the WORST IMPLEMENTATION
at the point wuere you wonder if it was purposely overly complex, non intuitive,
and non consistent.
This is a satire, right?
It is. This post is now over 8 years ago and was written in a time when developers has doubts about the distributed nature of version control.