This might be an exceptionally strange article for you to read. Perhaps you fully understand the enormous benefits that Git provides and perhaps your team (or yourself, for individual projects) has already made the switch to Git and you wouldn't think to use anything else.

Or maybe you use Mercurial. In that case please note that I when I say Git, I usually mean (Git or Mercurial). Usually.

But keep in mind that there are still teams or projects out in the world that are still stuck using SVN[1]. Or maybe even CVS (shudder). Those people are my target today.

Graph from Google Trends. See an interactive version here.

So now that we've got that out of the way...

Why Git?

Well, besides Git's own feature list, and besides this consulting article or this stack overflow discussion or this Atlassian talk addressing business needs and benefits or this article on Dr. Dobb's or this article suggesting moving specifically from SVN to Git or Linus Torvalds' talk let me try to come up with even more reasons.

It's everywhere

Git is practically an industry standard. If you know how to use Git:

• You're able to get started faster at new companies
• You're able to get started faster on new projects
• You're probably already familiar with pull requests so you can contribute easier to open source projects
• You don't fear branching, merging or having concurrent development paths
• (Here's the part where I have to hold back from just repeating the 7 linked articles above. For real, please read those articles).

But so what if Git is an "industry standard"? Well, for one, it means that there's a healthy Stackoverflow discussion (50,019 questions and 40,515 answers). In other words, someone has already run into whatever your problem is, has already asked it, and has already received an answer. By comparison, there are 16,507 answers for SVN, and 985 for CVS (as of this writing).

Graph from ArePeopleTalkingAboutIt.com. See an interactive version here.

It also means that the world wide web is rife with documentation, tutorials, and how-to guides. Or already a million essays advocating for it (whoops!).

It also means that there's a wide variety of modern plugins, tools, and integration points. There's entire services and businesses that have seen immense growth based solely around this tool (hi GitHub!). It's a huge platform.

Have you seen this awesome learning tool? Have you seen this fantastic visualization tool? Some nut job evangelists are so passionate about a revision/source control system (how does this happen?) that they made these websites to get you aboard the Git bandwagon. What a bunch of weirdos! It's just a RCS/SCS, right?

It's the "future"

I can imagine those of you who have already switched to Git laughing at this point. You're probably thinking I'm insane.

But there's people out there who don't realize that this April Git will be celebrating its 10 year birthday. Take a look at the initial commit if the world flew past you and you missed it. Git is not some new trendy tool that the cool kids are using. It's stable. It's robust. It's 10 years old. In the software/tech timeline Git is equivalent to the Mesozoic era on the prehistoric timeline.

Slide from Chris Aniszczyk's talk from 2010 while he was on the board of Eclipse (arrow added).

Companies all over have realized this. Did you know Microsoft has hosted open source projects on their CodePlex platform since 2006? Well, Microsoft is migrating .NET and many of its other open source projects over to GitHub off of Codeplex. Here's Microsoft's projects managed by Git and hosted on GitHub.

Google, not wanting to miss out of the fun, began hosting open source projects on their Google Code platform in 2009. But then they announced that they're migrating their Go language to GitHub off of Google Code. This was met with a positive reaction from the developer community and there was much praise for Git and Github. Google has many projects managed by Git and hosted on GitHub.

Or Facebook. Or Twitter.

Or look at it a different way, which popular tool or platform are you using that's managed by Git?

It's a fundamentally different revision control system

There's things about Git that make it so... special.

Linus Torvalds had good reasons to create it out of frustrations with SVN and previous revision control systems (RCMs). Or if you don't trust the guy behind Linux, consider Twitter's senior engineering manager's revelations in 2009 (while he was on the board at Eclipse). In 2010 he announced that CVS was dead and SVN is dying. You can see his dusty five year old slides stating that Git is the latest in the evolution of version control here.

Table from Eric Sink's history of version control

How's it special? For one it's distributed. What does this mean to you? In the interest of not repeating what hundreds (if not thousands) of other people have already already written about, please consult the links above. The TL;DR is that you reduce the single point of failures, you can commit and work faster locally, and you can collaborate better.

Git handles branching differently too. When was the last time you performed a branch on a large enterprise codebase in SVN? How long did it take you? It literally took me minutes. (Oh no, not entire minutes!) But the last time I branched a large piece of code in Git it literally took me fractions of seconds. Before you say, "So what if you just saved 8 minutes of time" let me tell you that when things happen orders of magnitude faster, you start to think about them differently.

Again, please consult the links above, but the TL;DR is that you're never going to fear branching or merging again. And Git will never result in any weird branching or merging errors that you'll occasionally see while using SVN. And that makes entirely new development processes possible, such as always having a stable trunk, and only releasing releases when they're stable and ready (weird idea, I know). It's almost like Git can be used to achieve that tech-babble "continuous integration" thing that people keep talking loudly about, whatever it is.

So... how do you switch?

If you're starting a new project it's easy. Just use Git from the beginning (well duhh!). All it takes is a simple git init in the project's root directory. You can commit all you want and down the road you can decide to open it up to others by pushing to a remote like GitHub/GitLab, or having others clone from you. My rule of thumb is that if I spend longer than a few hours on unversioned code or I'm about to perform any rewrites / refactoring (or anything slightly "risky") I'll initialize and commit to a local Git repository.

If you're on a big team that refuses to make the switch, you can use the git svn command outlined here to get some benefits of Git while at the end of the day checking into a canonical SVN repository. From their docs:

This means you can do local branching and merging, use the staging area, use rebasing and cherry-picking, and so on, while your collaborators continue to work in their dark and ancient ways.

But I cannot fully recommend using git svn like this if you have the opportunity to migrate entirely away from SVN. From their docs, which is worth repeating:

If you follow those guidelines, working with a Subversion server can be more bearable. However, if it’s possible to move to a real Git server, doing so can gain your team a lot more.

Which comes to the final issue...

How can you make a transition from say, SVN, to Git in the most pain free way possible?

GitHub or GitLab (an internally hosted equivalent to GitHub, for those companies afraid of the cloud) do wonders to ease the transition. They both provide a fast, intuitive, web-based UI to help visualize your project as it's managed by Git. You get pretty charts, graphs, and helpful collaborative tools that build into your existing process instead of adding vertically (overhead) to a process.

If you see the light while your coworkers remain in the dark, consider updating the internal wiki at your work with a concise tutorial (full of pretty pictures -- everyone likes pictures) for installing Git on your local machines or creating SSH key pairs. If you don't have an internal wiki, consider a tutorial-in-an-email for your team. You may want to document how you installed say, the Git plugin for Eclipse or how you got Maven/Gradle/Ant/Make/Jenkins/Hudson/Nexus/whatever to interface with it.

Stackoverflow has a great discussion here on migrating from SVN to Git if you have a big meaningful SVN history (hint: scroll past the accepted answer). This guide talks about handling all your authors and this guide talks about handling all your branches and tags. Both use the git svn command as part of the migration.

If you have no interest in keeping your SVN history and if you're only on one trunk in SVN, you can just checkout from SVN, git init, use Git's ignore feature to ignore all the pesky .svn files scattered everywhere, and then make your initial git add . and git commit to the new Git repository. Make that repository accessible, either by pushing to GitHub/GitLab, or by following this brief but excellent guide. You and your teammates can now use Git. Also then please read this to because you're missing the point of commit messages.

Am I crazy or are you crazy*?

Finally, if you can provide any compelling reasons to keep using SVN or any previous source control management / revision control tools please share them below.

Additionally, if you can offer any easy ways to make a migration to Git easier, perhaps from SVN or your previous revision/source control system, please let me know.

Are you using something newer, better, more amazing than Git? I'd like to hear about it too.

* It's cool, we can both be crazy[2][3].

---

[1] I was very hesitant to share this slide from the 2014 Eclipse Community Survey of 876 respondents because from first glance, it's quite misleading. If you focus on 2014 Git holds the majority ringing in at 33.3% relative to second place, SVN at 30.7%. Not only that, but there are separate categories for Git and GitHub, but you're only supposed to choose one (!!!). I'd wager that almost all of the folks using GitHub are also using Git, so a better representation would look something like this. Keep in mind that's already a year old and Git has seen explosive growth while SVN keeps shrinking.

[2] I'm guessing some of you will say you have a ton of legacy systems or build processes that rely on SVN. Sure, I understand the hesitancy to make the switch. But I bet it's easier than you think it is, and any 3rd party tool worth its salt should have integration points for Git at this point in time. Or if it's actually that hard to migrate some special home-brewed tool, you already know this and the 100th essay you read about this amazing tool isn't going to convince you anyways :)

[3] Worried of a big monopoly on source/revision control systems? If everyone uses Git, will Git no longer have any compelling reason to improve? We're probably okay as it's just an open source protocol. But what if everyone in the world one day uses GitHub... does GitHub have any compelling reason to improve? What if GitHub forks Git and develops it in secrecy, or introduces some non-compatible feature? These are not real concerns of mine, but it's good to be a little paranoid every now and then.