Agile Zone is brought to you in partnership with:

Paulund is a website dedicated to writing tutorials and code snippets about Web Development, the main subjects are PHP, Wordpress, jQuery, CSS3 and HTML5. Paul is a DZone MVB and is not an employee of DZone and has posted 140 posts at DZone. You can read more from them at their website. View Full User Profile

Version Control: Git vs SVN

  • submit to reddit

All developers should of heard the term version control before, but you might not fully understand what it is or what benefits it can give you in your projects. In this post we are going to look at the benefits of working with version control and the difference between two of the most popular version control repositories, GIT and SVN.

The simplest way to explain Version control is that it's used to keep a repository of your project files together with a history of all your code changes in one place. This allows the developers of the project to track every change made to the code, who made the change and the reasons for the code change.

These files will normally sit on a server away from your local developer machine which you will push your files to when you have completed coding.

It will also allow you to bookmark your code and certain points in time, making it easy to return to this point if a feature ends up breaking your code. Version control can be beneficial to a single developer on a project and it is essential for a team of developers working on the same project.

Why Use Version Control?

Version control is essential when working with a team of developers, if you are working in a team of developers and don't have version control, make sure everyone stops what they are doing right now and read this.

If you don't have version control, the only way you can work is by having your code in a shared location possibly on a network drive and you all access these files to make changes to the code. There are lots of things wrong with this way of working, first of all you can't have two developers working on the same file at the same time. If two developers are working on it, the last person to save will override all other code changes. Using version control will allow multiple developers to work on the same file at the same time, when they have completed their code changes they will commit them back into the repository. When you commit a file back into the repository it will merge your changes into version control.

Second problem with this is that there is no code history so if you create a new feature and demo it to the client and they decide that they don't want it anymore you would normally have to go through your code and remove everything you did. If you were using version control you could just revert your code back to before you started developing that feature.

The third feature that you can't use without version control is the blame feature. Version control will record who wrote a piece of code, which means if there is a piece of code that your not sure why it's there, you can use version control to check the code to tell you which developer wrote this so you can ask the developer to explain the reasons why it's there.

Version control is also a good way to keep your code shared on multiple computers, if you are a single developer but use both a desktop and a laptop to code when you switch between different computers you can just do an update on the repository and get all the latest code.

Tagging is an important feature you need to take advantage of when working with version control. When you have completed a piece of work and ready to deploy the code, you then tag this version of the code. This is essential creating a different branch of code at this current time. Then you can deploy your code from this tag, leaving you with the exact code that you have on the live server. The benefit to this is that if there was a problem with the current live version you can easily revert back to the previous tag.

Version Control Options

Now that you understand the benefits of using Version Control which one should you be using?

There are many different types of version control, here we are just going to look at the two most popular version control repositories, Git and SVN. Even though they are quite similar, the way you will work with these two repositories is going to be different. I'm not going to say which one is better than the other and which one you should be learning, this will have to come out of your own workflow and what you want to achieve with version control.


SVN or Subversion is very popular due to the fact that it's very easy to understand and very straight forward to work with. The WordPress plugin repository uses SVN.

It works by having a central server for your repository, this repository is split into 3 key areas...Trunk, Branches and Tags. Each one of these areas have an important role to play.



This area is where your stable code will live, no one should ever commit broken code into the trunk as this is the central area where everyone working on the project will get updates. When you are working on a new feature you should branch your code from the trunk, when you have finished coding your feature then you should merge all changes back into the trunk.


As explained above a branch is used when you want to create a new feature, so you branch the code from the trunk. This means that you take an exact copy of the trunk and place this into a new folder within the branches area. Now you can work on your feature within the branches area, when this is done you will merge your changes back into the trunk.

The benefit to this is that as you are developing your new feature you can make commits into the branch and know that you aren't going to break the trunk for anyone else working on the project, keeping the trunk as stable as possible.


A tag is a way of marking your code as a certain points in time, it is exactly the same as branching your code. As all they will do is take an exact copy of the trunk code and place this inside a new folder with the tag directory. The only difference between a tag and a branch is that tags should never be used for developing, they are there for an easy way of reverting your code back.

The time when tags are used is for deployments, when your new code is finished, merged into the trunk, has been fully tested and ready to be released this is when you will tag your code. You will make a tag on the trunk and mark it what the feature is for, you can now take this tag and deploy it to your live server. The benefit of doing this is that if your new release broke the website all you have to do is revert your code back to the previous tag.

As you never develop on tags, if you have broken code in your tag you should mark this tag as broken and branch from the trunk to fix the problem.


At the moment GIT is probably the most popular version control which is aided by the popular website Github. Like I said before GIT and SVN are quite similar but the workflow is a bit different. SVN has one central repository, but GIT has multiple repositories, one central repository but each developer has their own repository.

The benefits of splitting it up into multiple repositories is that there is no longer one single point of failure. With SVN if the central repository goes down or the code has broken the build then no other developers can commit there code until the repository is fixed. With GIT as each developer has the own repository it doesn't matter if the master repository is broke they can continue to commit code locally, until the master repository is fixed and then they can push their code into the master repository.

Another benefit of having a local repository is that it is quick, there is no network traffic needed to commit code into source control, developers can work in isolation until ready to push the code to the master repository.


The workflow that you use when developing using GIT is the following:

When working on a project you will clone the master repository, this means that you are making a copy of the code at this point in time. This creates a local GIT repository on your local machine where you can continue working on your new feature. You can use your local repository exactly the same as you would in SVN create new branches, tags, and continue committing code locally during development.

When your feature is complete and you are ready to merge your changes back into the master repository you need to push your changes from your local repository to the master repository. This is the slowest part of using GIT and is the same as a commit in SVN, but as you won't be doing this as often as a commit using GIT is very fast.

Version Control

I hope reading this has made you realise how important version control can be to your projects and you realise the differences between GIT and SVN so you can work out which one you prefer to work with.

There is one advantage of using version control that I didn't mention and that is automated deployments, this is because there are lots of things to go over and tools that can I'm saving this for a future post.

My version control choice is GIT this is because of how flexible and quick it can be used. I don't even have to connected to the internet and I have all the features I need from version control, which is perfect when travelling and working on a laptop. When you finally get an internet connection you can just push your changes to the central server and everything carries on as normal. With SVN if your working without an internet connection you have lost all the features of version control.

Published at DZone with permission of Paul Underwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Andre Gil replied on Wed, 2013/06/05 - 7:38am

With SVN you can have a master/slave configuration to address the single point of fail, also I didn't understand why you need a internet connection, what you need is a connection to the SVN server, not to the internet. Almost all features are available if you are not connected to the server. excepted "merge" or administration task, I agree the GIT is better than SVN, if you are not connected to the server, because you have a "full local" repository.

Andries Spies replied on Sat, 2013/06/15 - 5:13am

This article misses the point of GIT. It is distributed. Authors work on they own repo, and issues pull requests to upstream authors, which has to review, and then pull in the code. 

With svn anyone can just puke code into your repo, leaving you with the mess. I strongly suggest viewing Linus presentation on Git to Google: Here is the link

Most corporate developers have been so indoctranated by corporates centralized command and control structures that they cannot see the benefit of something like GIT's decentralized workflow. 

Mykel Alvis replied on Wed, 2013/06/19 - 12:26pm in response to: Andries Spies

 Huh?  Did we read the same article?  The author here didn't miss the point of git at all.  The point of the article is that there are multiple valid ways of doing source-code management but you need to figure out which one works in your environment.  My personal choice is to use whatever tool is currently being used or, if there's nothing, mercurial or git.  But that's because I know how to use those and about a dozen others.  For people who don't, the transition can be unsettling or simply not worth the effort.

I think you might be missing a point about how change isn't necessarily something that happens in any of the three axes of the project management triangle very well.  That is to say cheaply, quickly or correctly.

Irrespective of possible technical merits of a change, enterprise software development simply doesn't operate at the same speed as non-enterprise work.  Training 5 people to use a very new workflow for software development is a pain in the ass; training a 500 or 5000 would be ludicrously slow and expensive.  Beyond that, tooling for git has only recently hit the levels that subversion had for years.  I still laugh not-so-fondly at some of the earlier egit bugs.  Furthermore, but probably not finally, enterprises typically want [easily] centralized control of repositories.  Having Linus tell you you're stupid for doing it that way is yet another example of his charming ways, but might be because he works in what I only vaguely consider enterprise development. Before the various suppliers of git centralization (notably GitHub Enterprise), this was an onerous task that nobody did particularly well.

In most cases, it's not a question of seeing the benefit of anything. It's taking into account the various forms of change cost and the benefits expected.  It is painfully naive to think that switching from one mechanism to another will produce a superior result without taking into account the costs of switching, impacts on productivity or the possibility of serious failure.

I'm not qualified to judge most other people's experience with enterprise development, but I am quite familiar with my own. Without a doubt, the costs of switching something as intrinsic to the process as a source code management system for development at the scale at which I generally work has almost always been impractical.  Maybe one day these impracticalities will dissolve away without massive effort, but until then people will still use CVS, svn, Perforce, Bitkeeper, Accurev, Clearcase, SVK, TFS and VSS and a large number of other tools that may not work for them as well as you [or they] might like, but they probably work well enough to store source code and retrieve it.  Once they've reached the limit of their tolerance for their alleged pain, they'll invest in the change to something that they feel might serve them better.

Samir Naik replied on Tue, 2013/06/25 - 6:48am in response to: Mykel Alvis

Mykel Alvis, Excellent comment!

I could not have agreed more. The problem or at least the situation today is that there are more coders who work in small teams or even individually and just miss the big picture: Mere feature sets or even a radically new architecture is not sufficient to justify a switch. Stability over years of use and "does the current product do the job sufficiently?" are core issues/questions to be addressed/answered first not just in an enterprise environment but in any development scenario.

I would not switch from SVN until GIT stabilizes over a long period and the arguments in favor of GIT are just not compelling enough to justify a switch, even when it stabilizes.

Omar Gameel replied on Thu, 2013/12/12 - 5:48am

 Thank you Paul this was very useful

Steven Lundahl replied on Sun, 2014/06/08 - 8:04am

Thanks for the article, Paul. 

I do have one small clarification.  As someone who has administered on-site SVN installations for the past few years using VisualSVN, I'd just like to point out that SVN does support multiple repositories.  I have not used online SVN services which appears to be what you are commenting on so the implementation of SVN by the services with which you are familiar probably have not implemented the ability to have multiple repositories.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.