14 September 2009
Why You Should Switch from Subversion to Git
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.
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.017sIt 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' https://svn.example.com/trunk \
https://svn.example.com/svn/branches/myidea
real 0m5.172s
user 0m0.033s
sys 0m0.016s
$ time svn switch https://svn.example.com/branches/myidea
real 0m8.404s
user 0m0.153s
sys 0m0.835sNow 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.
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.
Enjoy this article?
If you liked this article, feel free to re-tweet it to let others know. Thanks, we appreciate it :)
We love .net Magazine
We're big fans of .net so they've hooked us up with a rad deal: Save 50 percent on your subscription.
Nils
# September 14, 2009 - 8:58 am
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.
Bookmarks for September 11th through September 14th « LostFocus
# September 14, 2009 - 9:01 am
[...] Carsonified » Why You Should Switch from Subversion to Git – [...]
Martin F
# September 14, 2009 - 9:07 am
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.
lottadot
# September 15, 2009 - 10:03 pm
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).
Eric Marden
# September 30, 2009 - 5:44 pm
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.
Weekly Link Dump #1 | Dmytro Shteflyuk's Home
# September 14, 2009 - 9:49 am
[...] Why You Should Switch from Subversion to Git [...]
AlastairC
# September 14, 2009 - 10:11 am
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?
Kari Pätilä
# September 15, 2009 - 7:35 am
Did you mean something like this:
http://joemaller.com/2008/11/25/a-web-focused-git-workflow/
Eric Marden
# September 30, 2009 - 5:46 pm
You would just replace ’svn up’ with ‘git pull’ (provided its tracking the right branch) and ’svn info’ with ‘git show’ and it would be the same process.
Damien L
# September 14, 2009 - 10:34 am
@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
Chetan Sachdev
# September 14, 2009 - 10:42 am
Very nice post. your post force me to look at Git and use it :)
Thank you
Fabio Varesano
# September 14, 2009 - 11:07 am
Hey, you also should have a look at Bazaar http://bazaar-vcs.org/ .. that’s the VCS used by some by projects like Ubuntu and MySQL..
I’m using it and I’m really happy.
Dan Benjamin
# September 14, 2009 - 12:13 pm
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.
cisnky
# September 14, 2009 - 4:39 pm
Very informative article, I’ll definitely be taking a second look at Git.
Thanks.
Chris
# September 14, 2009 - 5:11 pm
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.
Chad Lindstrom
# September 23, 2009 - 8:08 am
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.
John
# September 24, 2009 - 12:33 am
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
Timmy Christensen
# September 14, 2009 - 6:34 pm
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.
Chad Lindstrom
# September 23, 2009 - 8:11 am
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.
John
# September 25, 2009 - 2:46 pm
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
Jim Morrison
# September 14, 2009 - 8:35 pm
Thanks for the article Scott, definately take a look…
… was about to dismiss the whole idea but since git seems to be happy trac – which rocks! – maybe it’s worth a look!
http://www.google.co.uk/search?q=git+trac
Is tortoisegit particularly stable??
J.
Henry Ho
# September 14, 2009 - 9:10 pm
How mature is TortoiseGit? Is it ready for prime time?
Derek Scruggs
# September 15, 2009 - 3:22 am
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.
Eric Marden
# September 30, 2009 - 5:51 pm
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.
Edmundito
# September 15, 2009 - 4:09 am
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?
Ben Scheirman
# September 15, 2009 - 9:15 pm
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….
Ben Scheirman
# September 15, 2009 - 9:16 pm
Whoops, this reply was intended for Raymond :)
| MarcJStuff
# September 15, 2009 - 5:02 am
[...] Why You Should Switch from Subversion to Git [...]
flat53 » Blog Archive » Git vs SVN. You know the winner!
# September 15, 2009 - 6:05 pm
[...] http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ [...]
manish
# September 15, 2009 - 7:32 pm
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?
Angus
# September 15, 2009 - 8:12 pm
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.
Ben Scheirman
# September 15, 2009 - 9:19 pm
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.
Oisin
# September 16, 2009 - 3:09 pm
Eclipse plugin for git – http://git.or.cz/gitwiki/EclipsePlugin
Devon Hillard
# September 16, 2009 - 3:58 pm
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….
Random Links #47 | YASDW - yet another software developer weblog
# September 15, 2009 - 7:40 pm
[...] Why You Should Switch from Subversion to Git Ausführlicher, unterhaltsamer Artikel, warum git the way to go ist. [...]
bitsofinfo
# September 16, 2009 - 3:21 am
Interesting, I’m definately going to check out git
Chris Burbridge
# September 16, 2009 - 5:07 am
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.
John Ryding
# September 16, 2009 - 10:26 am
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)
mthorley
# September 16, 2009 - 4:08 pm
My this is Intererting ;)
Vassil Dichev (vdichev) 's status on Wednesday, 16-Sep-09 16:25:56 UTC - Identi.ca
# September 16, 2009 - 4:26 pm
[...] http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ a few seconds ago from laconicabar [...]
Why You Should Switch from Subversion to Git | Lick My Chip !
# September 16, 2009 - 7:10 pm
[...] You Should Switch from Subversion to Git Via Hacker News by (author [...]
FBI #3 « Kevin Colyar
# September 16, 2009 - 10:54 pm
[...] Why You Should Switch from Subversion to Git – “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.” Kevin Colyar Posted in: Blog, From the Browser Inbox Tags: wordpress, thumbnail [...]
links for 2009-09-16 « Mandarine
# September 17, 2009 - 4:09 am
[...] Carsonified » Why You Should Switch from Subversion to Git (tags: git toread) [...]
Chain Links #031 | Proc#curry
# September 17, 2009 - 5:32 am
[...] Why You Should Switch from Subversion to Git Wait, what? Git? What’s that? [...]
eremit (eremit) 's status on Thursday, 17-Sep-09 07:58:21 UTC - Identi.ca
# September 17, 2009 - 7:58 am
[...] http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ a few seconds ago from choqoK [...]
Manuel Paccagnella (manuelp) 's status on Thursday, 17-Sep-09 19:25:20 UTC - Identi.ca
# September 17, 2009 - 7:25 pm
[...] http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ a few seconds ago from IdentiFox [...]
Destillat KW38-2009 | duetsch.info - GNU/Linux, Open Source, Softwareentwicklung, Selbstmanagement, Vim ...
# September 18, 2009 - 5:18 am
[...] Why You Should Switch from Subversion to Git [...]
An Independent Game Developer’s Diary » Blog Archive » Bookmarks for August 27th through September 21st
# September 21, 2009 - 11:05 am
[...] Why You Should Switch from Subversion to Git – [...]
Ennuyer.net » Blog Archive » Rails Reading - Sept 21, 2009
# September 21, 2009 - 3:02 pm
[...] Carsonified » Why You Should Switch from Subversion to Git [...]
Git at Eclipse « EclipseSource Blog
# September 22, 2009 - 2:47 pm
[...] Read Why you should switch from SVN to Git [...]
Revue de presse | Simple Entrepreneur
# September 24, 2009 - 5:47 am
[...] Why you should switch from Subversion to Git Git est un gestionnaire de versions qui a reçu énormément de publicité cette dernière année. Mais s’agit-il d’un simple phénomène de mode ou faut-il réellement abandonner un outil comme Subversion qui remplit déjà bien son rôle ? [...]
NinjaCross
# September 24, 2009 - 11:02 am
Nice article, indeed Git is something I’ll look at during my next holiday :)
Michael C. Harris (michaeltwofish) 's status on Thursday, 24-Sep-09 11:41:46 UTC - Identi.ca
# September 24, 2009 - 11:41 am
[...] http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ a few seconds ago from xmpp [...]
Mes favoris du 24-09-09 au 25-09-09
# September 25, 2009 - 8:23 am
[...] Carsonified » Why You Should Switch from Subversion to Git [...]
Bookmarks for September 21st through September 25th | Jesse Bilsten
# September 25, 2009 - 6:31 pm
[...] Carsonified » Why You Should Switch from Subversion to Git – Describes how to use Git and the advantages to it being a distributed architecture and version control system. [...]
51taola
# October 9, 2009 - 3:12 pm
A good article, learning the
Jim
# October 14, 2009 - 7:49 pm
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…
Henri Bergius: Open Source and why forking is good | Full-Linux.com
# October 15, 2009 - 6:06 am
[...] what FSJ is talking about is forks being beneficial by themselves. This is the model that Distributed Version Control Systems like git also promote: every developer has their own fork of the software, and merges to [...]
Best of the Web: September | My Blog
# October 17, 2009 - 7:04 am
[...] Visit Article [...]
Puzzle ITC (puzzleitc) 's status on Monday, 19-Oct-09 09:30:09 UTC - Identi.ca
# October 19, 2009 - 9:30 am
[...] you should switch to #git: http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/ [...]
What Mother never told you about SVN Branching and Merging « Design By Gravity
# October 19, 2009 - 2:25 pm
[...] Mother never told you about SVN Branching and Merging Developers are fond of recounting their disastrous experiences branching and merging in Subversion and [...]
Ironic John
# October 30, 2009 - 12:26 am
Your comment form is too small.
git top links: 2009-11 « git blog
# November 8, 2009 - 12:39 pm
[...] Why You Should Switch from Subversion to Git (384): Very detailed article that summarizes the advantages of Git over Subversion. [...]
What Mother never told you about SVN Branching and Merging « Мързеливец и Co.
# November 12, 2009 - 2:50 pm
[...] are fond of recounting their disastrous experiences branching and merging in Subversion and [...]
Gnu
# December 23, 2009 - 4:23 am
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.