Why You Should Switch from Subversion to Git

Kevin and Gary show at FOWA London

You may have heard some hubbub over distributed version control systems recently. You may dismiss it as the next hot thing, the newest flavor of kool-aid currently quenching the collective thirst of the bandwagon jumpers. You, however, have been using Subversion quite happily for some time now. It has treated you pretty well, you know it just fine and you are comfortable with it – I mean, it’s just version control, right?

You may want to give it a second look. Not just at distributed version control systems, but at the real role of version control in your creative toolkit. In this article, I’m going to introduce you to Git, my favorite DVCS, and hopefully show you why it is not only a better version control system than Subversion, but also a revolutionary way to think about how you get your work done.

Now, this isn’t really a how-to on Git – I won’t be going over a lot of specific commands or get you up and running. This is a list of arguments on why you should be seriously considering Git if you’re currently using SVN. To learn Git, there is a free online book called Pro Git that I wrote that will walk you through Git step by step, should this article entice you. For each point I make here, I will be linking to the appropriate section of that book, should you want to find out more about that specific feature of Git.So, first we’re going to look at the inherent advantages of distributed systems over centralized ones. These are things that systems like Subversion simply cannot do. Then we’ll cover the powerful context switching and file crafting tools that are technically possible to do with Subversion, but which Git makes easy enough that you would actually use them. These tools should completely change the way you work and the way you think about working.

The Advantages of Being Distributed

Git is a distributed version control system. So what does “distributed” actually mean? Well it means that instead of running `svn checkout (url)` to get the latest version of your repository, with Git you run `git clone (url)`, which gives you a complete copy of the entire history of that project. This means that immediately after the clone, there is basically no information about that project that the server you cloned from has that you do not have. Interertingly, Subversion is so inefficient at this that in general it’s nearly as fast to clone an entire repository over Git as it is to checkout a single version of the same repository over Subversion.

Now, this gives you a couple of immediate advantages. One is that nearly every operation is now done off data on your local disk, meaning that it is both unbeliveably fast and can be done offline. This means that you can do commits, diffs, logs, branches, merges, file annotation and more – entirely offline, off VPN and generally instantly. Most commands you run in Git take longer to type then they do to execute. Now stop for a moment and try to remember how many times you’ve gone to get a cup of coffee while Subversion has been running some command. Or jot down a quick list of occasions on which you’ve wanted to commit but didn’t have an internet connection or couldn’t connect to your corporate VPN.

The other implicit advantage of this model is that your workflow does not have a single point of failure. Since every person working on your project has what is essentially a full backup of the project data, losing your collaboration servers is a minor inconvenience at best. Imagine for a moment your SVN server having a hard drive corruption – when was your last backup and how many hours will it take to get to the point where your team can start working again? In Git, any team member can push to any server where every member has SSH access and the whole team can be easily up and running in a matter of minutes.

The final advantage I’ll cover of distributed systems are the incredible workflows that are now available to you. Git does not depend on a centralized server, but does have the ability to syncronize with other Git repositories – to push and pull changes between them. This means that you can add multiple remote repositories to your project, some read-only and some possibly with write access as well, meaning you can have nearly any type of workflow you can think of.

You can continue to use a centralized workflow, with one central server that everyone pushes to and pulls from. However, you can also do more interesting things. For example, you can have a remote repository for each user or sub-team in your group that they have write access to, then a designated maintainer or QA team or integrator can then pull their work together and push it to a ‘gold’ repository that is deployed from.

An example distributed workflow involving several Git repositories

You can build any sort of heirarchical or peer-based workflow model with Git that you can think of, in addition to being able to use it as a centralized hub as in SVN. Your workflow can grow and adapt with your business model.

You can also use it in other ways – an interesting example of this is deploying on the Ruby hosting company Heroku. To deploy to their systems, you simply push to your ‘heroku’ remote repository. You can develop and collaborate on other remote repositories, but then when you actually want to deploy your code to running servers, you push to the Heroku Git repository instead. Imagine trying to do that with Subversion.

Lightweight Branches: Frictionless Context Switching

Before I begin explaining this, which is actually my favorite feature of Git, I need you to do me a favor. Forget everthing you know about branches. Your knowledge of what a ‘branch’ means in Subversion is poisonous, especially if you internalized it pre-1.5, like I did, before Subversion finally grew some basic merge tracking capabilities. Forget how painful it was to merge, forget how long it took to switch branches, forget how impossible it was to merge from a branch more than once – Git gives you a whole new world when it comes to branching and merging.

In Git, branches are not a dirty word – they are used often and merged often, in many cases developers will create one for each feature they are working on and merge between them possibly multiple times a day, and it’s generally painless. This is what hooked me on Git in the first place, and in fact has changed the entire way I approach my development.

When you create a branch in Git, it does so locally and it happens very fast. Here is an example of creating a branch and then switching to your new branch to start doing development.

$ time git branch myidea
real	0m0.009s
user	0m0.002s
sys 	0m0.005s

$ time git checkout myidea
Switched to branch "myidea"
real	0m0.298s
user	0m0.004s
sys 	0m0.017s

It took about a third of a second for both commands together. Think for a second about the equivalent in Subversion – running a `copy` and then a `switch`

$ time svn copy -m 'my idea'  

real	0m5.172s
user	0m0.033s
sys	0m0.016s

$ time svn switch
real	0m8.404s
user	0m0.153s
sys	0m0.835s

Now the difference between 1/3 of a second and 13 seconds (not to mention the time it takes to remember each long URL) may not seem huge at first, but there is a significant psychological difference there. Add to that the fact that your network speed, server load and connectivity status are all factors in Subversion, where it always takes 1/3 of a second in Git and that makes a pretty big difference. Also, branching is considered a fast operation in Subversion – you will see even more pronounced speed differences in other common operations like log and diff.

However, that is not the real power of Git branches. The real power is how you use them, the raw speed and ease of the commands just makes it more likely that you will. In Git, a common use case is to create a new local branch for everything you work on. Each feature, each idea, each bugfix – you can easily create a new branch quickly, do a few commits on that branch and then either merge it into your mainline work or throw it away. You don’t have to mess up the mainline just to save your experimental ideas, you don’t have to be online to do it and most importantly, you can context switch almost instantly.

Now, once you have work on a couple of branches, what about merging? If you’re from the world of Subversion, you may cringe at that word, ‘merge’. Since Git records your commit history as a directed graph of commits, it’s generally easy for it to automatically figure out the best merge base to do a 3 way merge with. Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process – Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. I often do dozens of merges a day on certain Git projects of mine and rarely have even trivial merge conflicts – certainly nothing that isn’t predictable. Raise your hand if you’ve ever done a dozen branch merges on a Subversion project at least once a week and didn’t end each day by drinking heavily.

As an anecdotal case study, take my Pro Git book. I put the Markdown source of the book on GitHub, the social code hosting site that I work for. Within a few days, I started getting dozens of people forking my project and contributing

copy edits, errata fixes and even translations. In Git, each of these forks is treated as a branch which I could pull down and merge individually. I spend a few minutes once or twice a week to pull down all the work that has happened, inspect each branch and merge the approved ones into my mainline.

The Network Graph for the Pro Git project

As of the time of writing this article, I’ve done 34 merges in about 2 weeks – I sit down in the morning and merge in all the branches that look good. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes. Once again, I will leave it as an exercise to the reader to contemplate how that would have gone in Subversion.

Becoming a Code Artist

You get home on Friday after a long week of working. While sitting in your bean bag chair drinking a beer and eating Cheetos you have a mind blowing idea. So, you whip out your laptop and proceed to work on your great idea the entire weekend, touching half the files in your project and making the entire thing 87 times more amazing. Now you get into work and connect to the VPN and can finally commit. The question now is what do you do? One great big honking commit? What are your other options?

In Git, this is not a problem. Git has a feature that is pretty unique called a “staging area”, meaning you can craft each commit at the very last minute, making it easy to turn your weekend of frenzied work into a series of well thought out, logically separate changesets. If you’ve edited a bunch of files and you want to create several commits of just a few files each, you simply have to stage just the ones you want before you commit and repeat that a few times.

$ git add file1.c file2.c file3.c
$ git commit -m 'files 1-3 for feature A'
$ git add file4.c file5.c file6.c
$ git commit -m 'files 4-6 for feature B'

This allows other people trying to figure out what you’ve done to more easily peer-review your work. If you’ve changed three logically different things in your project, you can commit them as three different reviewable changesets as late as possible.

Not only that, which is pretty powerful in itself, but Git also makes it easy to stage parts of files. This is a feature that has prevented coworkercide in my professional past. If someone has changed 100 lines of a file, where 96 of them were whitespace and comment formatting modifications, while the remaining 4 were significant business logic changes, peer-reviewing that if committed as one change is a nightmare. Being able to stage the whitespace changes in one commit with an appropriate message, then staging and committing the business logic changes seperately is a life saver (literally, it may save your life from your peers). To do this, you can use Git’s patch staging feature that asks you if you want to stage the changes to a file one hunk at a time (git add -p).

These tools allow you to craft your commits to be easily reviewable, cherry-pickable, logically seperate changes to your project. The advantages to thinking of your project history this way and having the tools to easily maintain that discipline without having to carefully plan out every commit more than a few seconds before you need to create them gives you a freedom and flexibility that is very empowering.

In Subversion the only real way to accomplish the same thing is with a complicated system of diffing to temporary files, reverting and partially applying those temporary files again. Raise your hand if you’ve ever actually taken the time to do that and if you would consider the process ‘easy’ in any way. Git users often do this type of operation on a daily basis and you need nothing outside of Git itself to accomplish it.

Not Just for Teams of Coders

I hear from individuals all the time that this could not possibly be worth switching because they don’t work in large teams or don’t collaborate with other people at all. Or perhaps you’re not really a programmer, but a designer or a writer.

Well, on the individual versus a team front, I would argue that nearly everything I love about Git, much of which I’ve written about here, I love because it helps me, not because it helps my teammates. Screw them.

Local branching and frictionless context switching is entirely useful to an individual and probably the most unique and revolutionary feature of Git. In fact, I very often use Git like you might use RCS – just fire it up on some local directory and check stuff in every once in a while, having no remote repositories at all. Creating commits as logically seperate changesets is also helpful to you to remember why you did something a month ago, so those tools are also helpful on an individual level and finally, speed and backups are always a good thing, team or individual.

If you’re not really a software developer, I’ve already listed an example of using Git to collaborate on a book. Pro Git is being published by Apress, a major publishing company, and most of the writing and review of the book was done in Markdown using Git to collaborate. All the errata and translations are being handled in Git branches. You don’t know real writing bliss until you merge in a technical reviewers or copy editors modifications with something as simple as `git merge`.

In Closing…

In closing, this is really just the tip of the iceburg of awesome that is Git. There are tons of fantastic and powerful features in Git that help with debugging, complex diffing and merging and more. There is also a great developer community to tap into and become a part of and a number of really good free resources online to help you learn and use Git. The few things I’ve mentioned here are simply the features that most changed the way I think about working and version control. They are the major reasons I could never go back to a system like Subversion. It wouldn’t be like saying to me “you have to use a Toyota instead of a Mercedes”, it would be like saying “you have to use a typewriter instead of a computer” – it has forever changed the way I approach and think about creating things.

I want to share with you the concept that you can think about version control not as a neccesary inconvenience that you need to put up with in order to collaborate, but rather as a powerful framework for managing your work seperately in contexts, for being able to switch and merge between those contexts quickly and easily, for being able to make decisions late and craft your work without having to pre-plan everything all the time. Git makes all of these things easy and prioritizes them and should change the way you think about how to approach a problem in any of your projects and version control itself.

Treehouse

Our mission is to bring affordable Technology education to people everywhere, in order to help them achieve their dreams and change the world.

Comments

88 comments on “Why You Should Switch from Subversion to Git

  1. I prefer Mercurial over Git because its command line syntax isn’t as confusing. And it has a builtin repository server, how cool is that?

    “hg serve -p 80″ and everybody can access your repository using his browser or pull updates from it using mercurial. This makes team collaboration or simply syncing between two computers almost effortless.

  2. Pingback: Bookmarks for September 11th through September 14th « LostFocus

  3. If GIT weren’t so anti Windows I might, luckily TortoiseGIT is starting to look pretty good, so soon it might not be impossible to use GIT instead.

    • Martin, git-bash (installed when Git Windows installs) seems to have been working fine for me for the past few weeks.

      Infact, it has handled my ssh keys far better then TortoiseGIT has been. Though I’ve not had time to really look into why that is, so it may be I’ve not got TortoiseGIT configured correctly. (commits/adds work great, pushing to origin remote server doesn’t).

    • You’ll find that soon enough that Tortoise and other GUI clients are actually slowing you down and keeping you from realizing the true potential of ANY source control solution, including Git, SVN, etc.

      Embrace the command line.

  4. Pingback: Weekly Link Dump #1 | Dmytro Shteflyuk's Home

  5. Lots of good reasons there on the development side, but the first thing I wanted to check is how easy it is to run the ‘live’ version straight from the repo?

    I.e. in SVN I commit my changes, ‘svn up’ on staging, test it, and then do the same on the live server.

    Maybe it’s so simple people haven’t bother to mention it explicitly for noobs like me, but is there a simple way to do that in Git?

  6. @Martin: The only problem with Git on windows is getting started with ssh. If you’re already a cygwin or putty user, Git is not more difficult on Windows than on linux or osx. Windows might even have the best GUI tools for Git. You mention TortoiseGit; you should also have a look at Git-extensions:

    http://sourceforge.net/projects/gitextensions

  7. Another vote for Mercurial rather than Git. As great as Git is (and I use it every day working with my Rails cohorts), I prefer the simplicity and elegance of Mercurial.

    I’ve switched over all of my own projects from Git to Mercurial, actually, and only use Git on projects I’m not in charge of.

  8. Its the extra complexity of git that puts me off using it. I work in a group of people where I work on my own projects. Everyone else uses an age old versioning system I cant remember right now. And even though they hardly ever need to access my code through subversion, they occasionaly do, and it causes no problems, its simple. I think Git would blow their minds.

    • Yes, the complexity of Git threw off our team as well. We tried moving from SVN to Git, but in the end it just wasn’t cutting it. When you get into a problem with Git, where a file/merge borks on you, god help you. In SVN, it’s quite easy to recover from.

      Frankly, I get thrown off by the speed argument. Often, in a corporate environment, you will need to commit to an ssh repository. Which adds the overhead of committing over the network. Which is a big reason SVN will be slower. That aside, where do you spend most of your time, committing code, or editing code? What’s a few milliseconds, or, seconds?

      I’ve yet to truly experience *why* I need a distributed VCS. Yes, of course, I could be working on a plane, or in the arctic, or… let’s be serious just how critical this is. The only time I have been out of range or offline, I’m actually quite content to be offline. I’m probably on vacation, not working.

      • I’ve used git for a little more than a year. I’ve used svn for two years. In my current job, two or three out of 10-15 developers are using git, the rest use cvs. We round-trip from cvs to git back to cvs. Its a nuisance.

        I agree with you with respect to the advantage of working offline. Not really a big win. If I were still using subversion and my access to the host system were down, I’d just wait, have a cup of coffee, browse the web. My managers usually would understand about the delay. The business accepts these as the cost of doing business.

        I also agree with you about the speed of checkouts and commits. When my manager calls and tells me an emergency change is needed, if I were still using svn, he would not be mad if I told him I could not get started for 20 minutes until the latest trunk was checked out. Its not an advantage for me that git can checkout latest branch in less than a second.

        git does have many strange parts to it, I had a hard time keeping them straight in the beginning. Lets see, there is ‘checkout’, um…. ‘commit’, oh and ‘add’ that is a big one without that changes won’t be commited. So, that is one more command than subversion.

        Regards,
        John

  9. I’m still not convinced. We’ve recently done the big switch from Subversion to Git and it all seems like more work for some added benefits that I’m never going to cash in on.

    Maybe it’s just me, but I feel like the version control system shouldn’t get in the way of development and with Git I definitely feel like I spend more time pulling, branching and merging than actually writing code. It wasn’t this way when we used Subversion.

    • 100% agreed. We went down the same path in our team. We traced back that path, right back to SVN.

      I find there must be a lot of theoretical users of Git who rate Git vs SVN. Try it in practice folks.

      • I agree, too. Its usually alot easier to avoid change if we have some spectacular failures that suggest that change is bad. Avoiding change is good because then I can just get on with my job and avoid having to expend energy on learning, really, anything new. Truly, if an idea cannot be grasped readily, its not worth knowing.

        git is a terrific vehicle to help avoid change. Its a ‘new thing’ and has its excited proponents. Its real easy to convince my manager and co-developers to cut over to it in one big cut. Then, when when it fails and we roll it back, I can say: ‘See, change hurts!”. Then my manager will leave me alone so I can continue doing what I’ve always done.

        Its too bad git has a good story around co-existence with systems like subversion and cvs. My manager doesn’t have to know, but it helps to avoid the big-bang cutover from these tools to git.

        Regards,
        John

    • I agree entirely. I’ve been using Git for a few months now and I can’t really figure out what all the hype is about – sure, it’s got itself a nice sweet spot in distributed version control.

      SVN does everything I’ll ever need from a version control system and it does it well. I won’t be switching all of my projects to Git for that reason, the benefits just aren’t there for me.

  10. Question: how do you handle database stuff i.e. what if there’s a schema change? We run our stuff off a shared db on the server. That means you can’t do dev in a truly disconnected state, but I can live with that since I don’t travel much.

    • You should investigate Database Migrations, which are built into a number of Web Frameworks as well as some stand alone libraries. Distributed or Centralized, DB Migrations are a good idea period.

  11. Very interesting. I’ve been looking into distributed revision myself, and I’ve started with keeping personal projects under mercurial at home and at work and I can see the huge potential to keeping all of my code under revision control without making sad excuses. I can do weird hacks here and there, compare it with the previous revision without worry, whereas depending on a central repository you’re can get kind of worried about committing an experimental change to the code.

    However, the thing I wonder is what about non-programmers? how do we keep their heads straight in this system? I’ve seen that it’s hard enough for artists (I work in a media heavy industry: Video Games) to wrap their head around revision control and it seems to me that cloning and branching and merging their art files could mean a nightmare for them. In the web world, there are probably quite a few Photoshop files here and there in a particular project, and are those kept under source control? How does a designer keep the sanity of cloning and pushing back the changes they made back to the central repository?

    • You really should have each developer with his/her own local versions of the entire system. Changes from 1 person shouldn’t adversely affect others.

      This also leads me to think that you might not be storing your db scripts in source control. I certainly hope you are….

  12. Pingback: | MarcJStuff

  13. Pingback: flat53 » Blog Archive » Git vs SVN. You know the winner!

  14. Hello,

    Nice article. I was wondering what about support fir Git in eclipse. It there any such tool. Also what what about its integration with project management tools like Trac or Jira?

    • Yup, eclipse/web/jira integration. without these, git is a non starter for me. I have an INTEGRATED dev env for a reason. I want it FULLY integrated.

      • Really? FULLY Integrated? I bet you’d be more productive with the command-line than some uber-complicated Eclipse GUI plugin for Git.

        I think folks need to let go of the fact that Git thrives on the cmd line.

      • I totally agree with this. I use Eclipse+subclipse, Jira, Crowd, Hudson, etc… and it all hooks together nicely.

        subclipse isn’t an “uber-complicated Eclipse GUI plugin”, it’s a very simple way to manage versioning. It makes it easy to do branches, switching branches, tagging, updates, etc… Also, with Mylyn + Jira, it auto populates my commit notices with the appropriate Jira tickets, which in turn updates the Jira tickets with the code changes that happened for the ticket, etc….

  15. Pingback: Random Links #47 | YASDW - yet another software developer weblog

  16. Thanks, Scott!

    For whatever reason, Git makes sense to me. I set it up today and did some tutorials, and it works very nicely.

    Years ago, we used MS Visual SourceSafe, and it made sense to me (though apparently it had some issues).

    When I have tried to use CVS or Subvresion, it somehow did not work how I expected it to, but I feel that this just works.

  17. another SCM solution that I’ve fell in love with is from IBM’s Jazz line of products and their SCM solution. It uses the change set model to manage updates to your code, but has a wonderful GUI and does not get in the way of your development whatsoever. I’ve lost count of how many times i’ve done branches and merges that SVN would have cried over, but Jazz SCM handled wonderfully. It also has an import tool for SVN repos.

    http://www.jazz.net

    (Note: i’m a developer on this product, not SCM, but I use this everyday since we do Self-Hosting, and i’ve honestly been amazed with how simple it is and how much sense it makes from a UX perspective)

  18. Pingback: Vassil Dichev (vdichev) 's status on Wednesday, 16-Sep-09 16:25:56 UTC - Identi.ca

  19. Pingback: Why You Should Switch from Subversion to Git | Lick My Chip !

  20. Pingback: FBI #3 « Kevin Colyar

  21. Pingback: links for 2009-09-16 « Mandarine

  22. Pingback: Chain Links #031 | Proc#curry

  23. Pingback: eremit (eremit) 's status on Thursday, 17-Sep-09 07:58:21 UTC - Identi.ca

  24. Pingback: Manuel Paccagnella (manuelp) 's status on Thursday, 17-Sep-09 19:25:20 UTC - Identi.ca

  25. Pingback: An Independent Game Developer’s Diary » Blog Archive » Bookmarks for August 27th through September 21st

  26. Pingback: Ennuyer.net » Blog Archive » Rails Reading - Sept 21, 2009

  27. Pingback: Git at Eclipse « EclipseSource Blog

  28. Pingback: Revue de presse | Simple Entrepreneur

  29. Pingback: Michael C. Harris (michaeltwofish) 's status on Thursday, 24-Sep-09 11:41:46 UTC - Identi.ca

  30. Pingback: Mes favoris du 24-09-09 au 25-09-09

  31. Pingback: Bookmarks for September 21st through September 25th | Jesse Bilsten

  32. Very nice article. And, as it often is, the comments have been very enlightening as well.

    ps. just remember there’s ‘a rat’ in separate…

  33. Pingback: Henri Bergius: Open Source and why forking is good | Full-Linux.com

  34. Pingback: Best of the Web: September | My Blog

  35. Pingback: Puzzle ITC (puzzleitc) 's status on Monday, 19-Oct-09 09:30:09 UTC - Identi.ca

  36. Pingback: What Mother never told you about SVN Branching and Merging « Design By Gravity

  37. Pingback: git top links: 2009-11 « git blog

  38. Pingback: What Mother never told you about SVN Branching and Merging « Мързеливец и Co.

  39. Man…excellent article. U made me look outside the box. Developers who use svn from developer perspective will not realize most of what you say. I can see this from some of the comments. But having used svn both as developer and admin i now realize how far better git is over svn from admin perspective. Forget about branches..i live in a world with 3 mains go figure how many merges needed. Thank you for this article.

  40. Pingback: Jourdein » Blog Archive » I tried Git

  41. I just feel it waste my time. If I was forced to use this stuff. I don’t need to decentralize repository. It will need more disk space. who cares about history data always? And Git is not well built for windows at least now. SVN is good enough and can be imporved and it is open source. why do something from the scrach. I have meaningful job to do and do not want to spend my energy to tools similar.

  42. Interesting that you chose to compare Subversion over HTTPS rather than using it’s native protocol (which is much faster than using HTTPS). I’m not saying it would be as fast as Git, no idea just seems like a skewed comparison.

  43. Hey, very helpful article. I’m just getting into a situation where I need to choose my own CVS. This article is a fantastic writeup and exactly what I needed. It will be Git for me on my next project. Decision made…woo hoo!

    Now off to read that book you did on using Git…

  44. Sounds like Git is very much ‘flavor of the month’ which should sound warning bells to anyone who’s been in the software industry for more than a couple of years.

    The real important people to listen to are the ones who have used both. Here and in other blogs there are stories from people who’ve gone SVN -> GIT and then back to SVN. That speaks volumes.

    I don’t really buy the ‘SVN is hard to use’ line by many Git promoters. What’s so hard to use about SVN? What’s so bad about having a central repository? Isn’t that just smart revision control design anyway?

    • It seems, you didn’t get the point. I have been using SVN for quite a long time and switched to Git last month. I don’t even want to think about SVN anymore, as I don’t want to think about a “typewriter” now that I have a “computer” (nice analogy).
      First, with Git you are never worried about something going wrong, because nothing can go wrong (ok, unless you format your disk.)
      Second, in Git you can, so easily, switch the context (using branches) and go in any direction you want. With this your code becomes your guinea pig. You can do whatever experiment with it you want. With SVN you wouldn’t go for such adventures. This is why I fell in love with Git.

      Of course, there is much more to Git as the author points out. (By the way, very nice article)

      But I recommend you to read a book so that you understand Git’s philosophy and how exactly it works before using it (make sure you understand what is index and what is staging). I read the book “Version control with Git”. I liked it very much.

      • “… because nothing can go wrong…”
        Mate, don’t say things like that if you want any credibility!

    • I’ve been using both for a while now. The thing I love about GIT is it’s lightweigth branching. I can switch between features in seconds, and not dirty up my code. No more problems with reverting code that I don’t actually plan to finish for the given sprint/release.
      I currently have a setup where I work with SVN as the company defined version control system. I have SVN setup with Eclipse. Then I create a GIT repo for me locally, and have the benefit stadet above. When I’m finished with all my features, I merge the branches to the GIT ‘master’ branch, an commit to SVN from Eclipse.

      On more thing regarding ‘flavor of the month’. Many importan projects (like the Linux kernel, and Google Android) are on GIT, so that should count for something as for stability and usability :)

  45. On the ‘I am working alone’: I *am* a distributed team. While I’m the only commiter on many things I do, git comes in quite handy to keep the project synchronized between my laptop and the two test machines.

  46. You missed my favorite git command, stash. STASH! If you have been working on something and need to do a quick rollback to put out a fire:
    git stash
    You’re rolled back, you can make changes, commit, push, pull, whatever.
    git stash apply
    Your back to where you were before the interruption. Life saver.

  47. Am I the only one who finds SVN branching simple and easy to use? I didn’t know it was supposed to be a dirty word.

  48. Interesting and informative article. But a bit disappointed that the article wasn’t “fair”; that is, by also providing advantages of Subversion. Of course, given the article’s title, I doubt being fair was one of its aims…

    Someone pointed out below the [somewhat unfair] comparison of time based on using Subversion using the http protocol. Actually, there is something else that (IMHO) is misleading. In Subversion, if you’re disconnected from the Internet, you can still do “svn [add|remove|etc.]“. Only when you want to do a commit do you need an Internet connection. So, you can be away from the Internet and do heaps of adds, removes, etc. Likewise, you can do an “add” and then “remove” without doing a commit — the net effect is that what you wanted to add was never added.

    While I get the point that with git, you have a copy of the repository, in the end, if you are away from the office and don’t have an Internet connection and your computer dies, you also lost everything. I mean, if you know what happens behind the scenes of git and Subversion, I can see git has advantages; but if you think about it as “is my work safely put away?” or “can others see my work?”, then the answer has nothing to do with Subversion or git — it has more to do with whether you’re connected to the Internet.

    Anyway, nice article (really!). Before I decide, I might find an article on why I shouldn’t switch. :-)

    • > Actually, there is something else that (IMHO) is misleading. In Subversion, if you’re disconnected from the Internet, you can still do “svn [add|remove|etc.]“. Only when you want to do a commit do you need an Internet connection.

      What’s the point of making svn add/delete files when you have no real connection to the repository? You don’t save any steps from committing your changes back to the repository. And without real connection to the repository you can’t save your changes back to the repository, period.

      The thing that is missing from a centralize source control repository is : you have NO local history that you can back out of, recover from, or compare with. Now, all you SVN-gurus please tell me how do you preserve your work locally without committing back to the repository? Do you always cut a branch when you even work on a small bug fix? How about when you want to experiment something but don’t want to add/commit to the trunk and your other co-worker can’t see what you are working on without you committing it to the repository?

      If you have never encountered this type of situations, then the tool is NOT FOR YOU, period, there is no need to bash the idea that this tool might work better for others when where the SVN falls short really matters to the project to those people.

  49. Yeah I wonder if the author compared speed of git & svn on the same server. SVN only seems as slow as the server in my limited experience. Not that I prefer SVN, just saying.

  50. Pingback: Getting Into the Flow with Git | The Phuse

  51. There was a rat in each of Scott’s “seperate” mistakes. Maybe you could come up with a clever reminder that included a use of the word “par” instead.

  52. Incidentally, because of the ‘pristine copies’, a svn sandbox is usually bigger than the complete project history that git carries around in compressed form.

  53. why do something from scratch?

    because programming is craftsmanship to me, and i get off on improving myself as a programmer. decentralized is more elegant, more flexible, and more philosophically appealing…like torrents.

  54. where is the letter “a” before “rat” in each of the mistakes? “a rat” not “rat”…

  55. where is the letter “a” before “rat” in each of the mistakes? “a rat” not “rat”…

  56. This is true, I’m a command line guy, and git + command line is the best thing since chocolate milk. But it’s really hard pushing this onto people who like working from GUI tools. I’m very sad that EGit is still very unstable and bug prone … this along side with tortoiseGIT is what is stopping us from full GIT adoption.