Git for Svn users

Mon, Feb 10, 2014 Introduction

Git and Svn or subversion are the most used control versions systems today. The two versions have some similarities and also differ in some way. Understanding the similarities between these systems should be the key element for those users who use Subversion but want to learn Git.

Over the years, Subversion has been on the lead and this is because of its simplicity and also its nice user interface. It was good  to handle centered tasks for independent developers. With time developers needed a system that they could collaborate and work on very large projects, a system that is built on speed and also secure platform. Subversion could only meet a few of these developers needs. Git on the other hand, was already a powerful collaboration tool, that offered code review, and code management for open source and private projects. They found it to be a distributed version control system that was perfect to handle everything from small to very large  projects with speed and efficiency.

At the moment, Git control version is on the demand and most developers who were conversant with other control versions like Svn are continually crossing over to Git platform. In this articles we are going to weigh the advantages of using both Git over Svn and why you should consider Git as your primary development tool.

Making shifts

Since Svn and Git relate in somehow in few features, transferring source code from Svn to Git and vise versa is a common behaviour. However, this transition is normally a tedious process and time consuming as well. But most of time it is necessary to do so if you happen to join a group that is strictly Git or Subversion control system. Working on a such circumstances is usually challenging because of the fact that the two systems differ. In most circumstances, Svn users struggle adapting to Git environments as compared to Git users adapting Svn. This is because almost the whole Git systems requires some a bit of understanding of how its features work.

When is the perfect time to shift?

There is no defined formula to switch from Svn to Git. Having used Svn for most of your projects and one day come across Git platform, there is no way you would continue your development without revisiting Git. Its like the way you type all your documents using notepad for Microsoft and then one day you type in Microsoft Word. Would you still stick to Notepad or you would go for Microsoft’s Word? Well, thats for you to decided!

Svn a centralized control version

Subversion (Svn) is one of the popular centralized control version system used by developers. It is stable and supports a variety of tools such as Track. However, there are other types of centralized control versions which are doing great like Cvs and Perforce. All of these versions have their own set of advantages and disadvantages too. But first, lets define the term centralized control system;

Derived from the word centre, you can easily tell what is meant by the term centralized control version system. This is a system that provides a single central basement (probably a server on the web) where a copy of source code is stored and only permitted programmers can “commit” changes to that central copy.



Figure 1: shows an example of centralized control version system.

Committing in Svn is that process of recording changes to the central source code of a software being worked on by a number of developers. The changes can be viewed by other team members, and they can either pull down the changes or let the control version tool to automatically update the files that were changed.

Changesets feature allows control versions to update a group of changes (or changes to multiple files) as a one cohesive unit. For example; a change on a D header code followed a change on the corresponding .d file should be treated as whole in by changesets.

Centralized system saves programmers from storing copies of files on their computer hard drives which can be stored in a centralized platform.

Git a distributed control version

Git control version was introduced six years ago to serve a purpose of distributed control version system. There are however, other control versions that are categorised as distributed systems like Mercurial and Bazaar.

Distributed systems do not inevitably rely on the central server for storage of all versions of a project’s files. Developers working on a single project can store copies of their repository with full history of the project on their hard drives. This process is referred to as “clones” in Git and usually contains all the metadata of the original. It occupies less space on your drives since clones are just codes which is usually text and a few images at times. Hence, no need to worry about your hard drive capacity.

Git do not prevent you from forming a single “central” repository, but instead, it provide even more options on top of that. For example, most activities against repositories are done locally, and thats includes accessing files on work, adding changes, and committing your files. Users share their files only when they are ready and also can grab on repositories that are not on their computer. Unlike centralized control versions where users push their changes at a central server, developers using Git push their changes to other team members directly or can as well allow users from the other end grab for themselves. The process of getting new changes from a repository is known as “pulling;” while “pushing” is the process of moving your own changes from a repository.



Figure 2: shows an example of a distributed control version system.

The power of collaboration through Git software

Git was built on focus to distributed type of control version. Speed was highly emphasized, as well as security and stability. Today, many team of developers around the world collaborate use Git softwares to create open source softwares like linux and Android.

Jumping from a centralized to a distributed control version

Many Independent developers, teams, and organizations are constantly switching from centralized versions like Svn to distributed version control like Git. Git has been populated with more users as compared to other versions of distributed systems. The readily available training materials on the web for new Git users, have largely contributed to this migration.

In conclusion

Taking time to understand how Git is important in the current entire development industry as a whole, is only a step towards Git. Nevertheless, learning how to use Git is easier like never before for Svn users. There more valuable tutorials over the internet showing in simple terms how to get started with Git. Right from the basics, you can learn things like doing changes in Git, Git branches, rewriting Git history, remote repository, workflows, file managements, and more! and for experts, migrating from Svn to Git should be an overwhelming task at all. You can use guiding resources from the web.