Difference Between SVN and Git

In this post you will learn about SVN and Git and difference between them. Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system distributed as open source under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation whereas Git  is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source-code management in software development, but it can be used to keep track of changes in any set of files. As a distributed revision-control system, it is aimed at speed, data integrity, and support for distributed, non-linear workflows.

Now let us see the difference between them. SVN is a Centralized Version Control System (CVCS), and Git is a Distributed Version Control System (DVCS).

A centralized version control system operates on the basic idea that there is one single copy of the project that developers will commit changes to, and where all version of the project are stored.

A distributed version control system, however, works on the principle that each developer “clolnes” the project repository to their hard drive. A copy of the project is stored on every developer’s local machine, and changes are either “pushed” up to the online repository, or “pulled” down from the repo to update the version that the developer has on their machine.

Git can be used to create a workflow that’s nearly identical to Subversion (SVN), except that it requires an extra step. Since the commits are made on your local copy of the repository, you need an extra command (push) to share these changes to the central shared repository. Since Git also allows you to control what you commit through staging changes to the index, there’s also a step there, though you can bypass that step with flags to the commit command.

If you plan to use Git in this way, SVN and Git are about equal. SVN is simpler, with fewer steps. Modern versions of SVN have made branching and resolution of branch merges work better, so there’s little to no advantage for Git in a centralized workflow. The only advantage Git has here is that you can continue making commits without access to the central repository, and merge those changes with the upstream changes later. The downside is that to maintain a clean history, you have to know when to do a rebase instead of a merge. This isn’t hard to learn, but it’s more complex than SVN.

However, Git makes it easy to use other workflows like Feature Branching, Gitflow, and Forking (aka GitHub) workflow. Git offers a lot more flexibility in how you can collaborate, which is a big reason for using revision control in the first place. It makes forking a project a trivial 1-step action — every clone of a repository is essentially already a fork — which is one of the reasons it has become popular within the open source community. This flexibility and power means that the primary reason to choose SVN these days is that it’s what’s already in use. And since you can actually use Git concurrently with SVN, for contributors to a repository, even that’s not always a good reason.

Git’s graph-based revision model makes it more powerful for branching, merging, and resolving conflicts. SVN has made significant improvement in this area in the last few years, but pressure from Git was a major reason for these improvements. Managing a Git repository is also much easier, and requires a lot less administrative overhead (granting special permissions, etc.). Git also gives all users a lot more tools to examine and work with repositories.