While there are many articles on the Web comparing the two version control systems (VCSes) Subversion (SVN) and Git (i.e. SVN vs. Git), many of them are overly technical. This one, however, attempts to provide a higher-level business case for making the switch.

Background

SVN is a member of the previous generation of VCSes, those that are centralized. Git, on the other had, is a member of the latest generation, distributed VCSes. Like Mercurial and Bazaar, Git subscribes to a concept of repositories communicating with one another (nodes in a network) rather than following the previous generation's hub-and-spoke model. Git, though, has become the industry leader, and is considered by some to be the de facto option for version control.

Core Advantages

1. It's faster. Because each “checkout” (SVN-speak) of a Git repository is a complete self-contained copy (referred to as a “clone”), nearly every operation is performed on the local disk's data. This is incredibly fast compared to performing operations over a network, and they appear to take place almost instantly.
2. It doesn't require a network. As most operations are local, they can be done off-line, without an Internet connection; communication with a remote system is not required. For example, commits, file differences, logs, branches and merges are not dependent on access to one's corporate virtual private network (VPN). So not only is VPN access unnecessary, any network connection is often unnecessary.
3. It removes the single point of failure. Unlike Subversion, where there is only one central repository with which all clients must synchronize, each repository clone in Git is in fact an full copy. So each developer working on the project essentially has a full backup of the data. If the server hosting the authoritative Git repository fails, it would be inconvenient, but most (if not all) data could be recovered by having a client push his or her repository to another server. This is in stark contrast to SVN, where it would be necessary to recover a backup and then recreate any updates since the snapshot was taken.
4. Branching and merging is simpler. Git's lightweight branches along with its merging strategy make merging seemingly disparate changes in SVN trivial. While Subversion does not consider the full directed acyclic graph when searching the history to find the correct merge base, Git does. It allows for workflows that, when compared to SVN, would be much trickier to implement.
5. Any subset of changes can be committed. Git introduces the concept of a staging area for committing changes. All modified files do not need to be committed at once. If a developer is working on many changes, it's possible to logically separate each of them and commit sequentially. This is not only on a per-file basis; multiple changes within each file can be separated. Without this capability, the user would need to clean his or her working copy before preparing each commit.
6. Files are directories are efficiently renamed. In Subversion, renaming files or entire directory trees actually leads to full deletions followed by full re-additions. This inefficiency leads to a bloated repository database, and can waste a significant amount of physical storage capacity. Git recognizes renames for what they are, minor changes to file and/or directory titles.
7. Repositories consume less space. With the same history, Subversion requires the same physical requirements as Git multiplied by a factor of thirty (30). That's 30x more drive space required to run SVN. This is due to both design and compression techniques.

Better Tools

As part of its core functionality, Git provides extremely useful tools that are not available with out-of-the-box Subversion. Some examples are listed below:

• Git Stash: Store working-copy changes elsewhere to quickly switch contexts. Stashed changes can be restored later. This is especially useful during development when a hotfix needs to be applied outside of the normal process.
• Git Bisect: Find the commit that introduced a bug. When provided with a known good commit and a known bad one, the command will have users test several times until it finds the bad commit. Uses very fast binary searching.

Value-Added Services

There are a good number of hosted services running on top of Git that provide user-friendly Web interfaces for managing projects. Services include user authentication, user authorization, issue tracking, merge requests, single-button merges, code review and line-by-line commenting on merge requests.

To name a few, popular services are GitHub (with fees for private repositories), Bitbucket (with fees for the number of users) and GitLab (with no fees at all for the Community Edition, and it's free/libre open-source software).

References

• Why You Should Switch from Subversion to Git
• GitSvnComparison
• How is SVN v 1.8 branching / merging compared to Git?
• From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development