Source control: Why we moved to Git

Andrew WillisPosted on 2nd Feb 2017

Share:

Source control is a vital tool for developers. It provides us with a way of letting multiple people work on the same file without interfering with changes made by others & provides us with an audit trail of who made what change as well as allowing us to see what our codebase looked like at a specific point in time.

For years, we had been using a system called Subversion, also known by the abbreviation of SVN, for this which, for the most part, worked very well. Recently though, we’ve migrated to another system, Git, to make our workflows more efficient.

You may be thinking something along the lines of “What’s the point of moving from one source control system to another?”. It’s a good question & one that I’ll attempt to answer here by describing the main advantages that we’ve found.

Distributed vs non-distributed

Firstly, let’s have a look at one of the main differences between the two systems: Git is distributed & SVN is not.

SVN has one single point of failure: the server that hosts your repository. Most commands that you execute through SVN will go through that server, be it to commit a change, switch to another branch or try to view the history for a specific file.

Let’s assume, for example, that either you or the server are experiencing network issues. This may at best slow down your work or at worst deny you access to your code because you cannot connect at all.

This is where the distributed element comes in with Git: you get a complete copy of a repository on your local machine which holds the entire history. This isolation allows you to work offline, shielding you from potential network issues while providing a much faster way of interacting with the repository.

You would more than likely still want somewhere remote to store the master copy of your repository so when you’ve finished making your changes locally you can then send them all to the remote master in one go. This can include any merges you may have done & for all branches that you’ve worked on. You can also have multiple remote repositories that you connect to if you want.

Branching

The next reason for migrating to Git was branching.

One thing we found with SVN was that, especially when working with larger projects, switching between branches could take a while. To deal with this we would often have different checkout folders for multiple branches that we could be working on.

With Git, this problem has gone as the local copy of the repository contains all the branch information. Even in the larger projects we can quickly switch to another branch as & when needed.

Because this is a quicker & more efficient process than with SVN we can now use a new branch for every single change that we make, be it a new feature or bug fix, even if it’s only a one line or one character change. This allows us to ensure that only production ready code makes its way into the main branch.

We can also have multiple branches for our different environments, e.g. one for our staging/ UAT environment & one for our potentially unstable latest developments.

Repository clean-up

The final benefit we’ve noticed is that we can clean up repositories a lot more efficiently & easily in Git than we could in SVN.

I’m sure that everyone’s had projects where someone has committed something in that they shouldn’t have. These could be passwords, a massive video file that should have been embedded from YouTube or the whole content of a WordPress ‘uploads’ folder.

To get rid of these in SVN required us to create a repository dump file, filter the offending path(s) out using ‘svndumpfilter’ & then load in the cleaned-up file. It was a laborious task which meant we soon got bored of it & started leaving non-critical data in the repository history.

When we migrated to Git we took the chance to clean up that type of data that had been left behind over the years. Using the awesome BFG Repo-Cleaner tool we could completely erase all history of the offending files or content before getting Git to clean up its internal files & uploading the cleaned repository to the remote master.

With some repositories, we managed to shrink the size by over 700mb, which makes quite a difference when you’re downloading a complete copy for the first time.

In conclusion, we’ve seen a few major benefits from switching to Git & I hope that this provides a good insight into why.

To learn more about what our developers can do for you, call the solutions team 020 3813 5351.