Version Control: Git vs SVN
Version Control: Git vs SVN
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
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.
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 help...so 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 , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.