Don’t use Git

no_gitEverybody 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

ic_action_collapseGit 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

ic_action_sadSVN 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

ic_action_usersWith 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

ic_action_playback_schuffleWith 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!

32 thoughts on “Don’t use Git

  1. 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. 😉

    1. Thanks, for pointing that spelling mistake out. You’re right, CVS is way simpler than SVN and the better repository technology.

      1. 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.

  2. 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.

    1. 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.

      1. Repository, just like internet has no physical weight. That means it’s worth, expressed as “weight in gold”, is nothing

    2. 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!

  3. 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.

    1. 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…

  4. 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.

  5. 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.

  6. 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)

    1. 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?”

  7. 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.

  8. 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.

  9. 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!

  10. 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

    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.

    1. 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s