Code versioning systems keep track of different versions of various programs and relevant flat files that the programs may use (e.g., initialization, configuration, parameter consumption, files etc.). Some people refer to them as SCMs (Source Control Managers) or VCSes (Version Control Systems).
Code from versioning systems can be read from a centralized repository and be written to a local drive. This is considered a pull. A programmer might pull code down to examine it, use it for testing, or modify it to enhance it or create new features. Being able to pull code down to various servers allows for aggressive experimentation. A developer can refactor code without a concern for the previous version(s). If something fails, the professional simply leaves the code alone (intact) as it resides on the centralized server (in a repository).
Code can be read from a local drive and written to a centralized repository. This is considered a push. You can push code up to make it available to other developers. The centralized repository thus acts as a backup mechanism for disaster recovery. (If the server that originally had the code is lost, the repository will have a copy of the file.)
Subversion is centralized (with one repository) and Git tends to be decentralized (with numerous repositories). For collaborative programming with multiple developers integrating their programs into a shared code base, Subversion may be more intuitive having a single source of truth (to control the code). For individual programming efforts, Git may be an easy way to store the history of various programs and/or configuration files for a personal project. Git does not require a web UI and is thus easier to set up. Git lends itself to recording different versions of a program in a local way without a separate server.
Both Git and Subversion archive code. Git repositories can be ultimately merged for a single source of truth. Conflicts of different check-ins for the same file from different developers can be reconciled. To discuss the details and options for this process of reconciliation is beyond the scope of this article. For beginners to understand version control, Subversion's web UI and its necessarily accompanying feature that requires it be centralized may be more understandable. Other code versioning systems often resemble Subversion in corporate environments (without the decentralization aspect).
For projects where people must connect to a VPN to upload new code, Subversion will not be as easy to use. Local Git repositories can be useful for programmers who work remotely. If they will not be able to connect to the corporate VPN, they may have code to check in and will be able to do so. Git will save the incremental changes locally when they cannot upload the code to a VPN repository. Eventually this Git repository will merge the changes when the developer finally connects to the VPN. Subversion does not have this system of recording changes for deferred synchronization while the remote development is in process. Git easily has the ability to save version changes of code locally. A centralized Git repository can be configured and used to later receive a replication of these changes from other remote, formerly disconnected Git repositories.
Some corporate environments disallow development from remote locations or off the corporate network. In this case connectivity to the network is guaranteed for any development to take place. Therefore Subversion would be equal to Git in this situation for this purpose. This limitation has the pragmatic effect of preventing redundant work from individual programming efforts.
Other than the centralization versus the decentralization features of the two code versioning systems, there are other differences:
Their Histories / Created In Different Years
Subversion was created in the year 2000, and Git was created in the year 2005.
Different Adoption Rates and Utilization
MentorMate's website shows that in 2014, the primary code versioning system adopted by various companies was Git with Subversion being the second most commonly used solution. From November 2016 until October 2017, the Subversion plugin for Jenkins has been downloaded more times than the Git plugin for Jenkins (according to this link for Git and this link for Subversion). OpenHub.net shows that Git is used more extensively than Subversion. As of 2016 zeroturnaround.com did a survey that showed that Git was much more widely used than Subversion.
In November of 2017 a search for jobs on Dice.com (with no location) with the keyword "svn" brought up 803 positions. The same search on the same day with the keyword "subversion" brought up 434 jobs. The same search on the same day with the keyword "git" brought up 3,364 jobs.
Different Inventors
- Git was created by Linus Torvalds famous for creating Linux.
- Subversion was created by CollabNet and is now supported by the Apache Software Foundation.
Subprojects Have Different Names
Both products lend themselves to disposable prototyping by allowing developers to pull code down and use a copy of a program. Subprojects in Git are referred to as submodules whereas subprojects in Subversion are referred to as externals (GitHub.com).
Other Meanings of the Tools' Names
- The word "git" used outside the context of I.T. in Great Britain means "a foolish or worthless person" (Merriam-Webster.com).
- The word "subversion" used outside the context of I.T. means the act of overthrowing something. To subvert is to undermine or destroy. Subversion is the act of subverting. In software (e.g., OS distributions) there are major versions (releases with new numbers in the ones place RHEL 6 vs. RHEL 7) and minor versions (decimal place changes) such as RHEL 7.3 vs. 7.4. Some versions are never released into production. Minor versions are subordinate in importance to major versions. Subversion can be a word to mean "mini-version."