Why GIT? Confessions of an ex-SVN user

 
 
 

When you have years of development experience you quickly learn what's important to your overall workflow. I mean if there were no IDE's I could survive with a basic text editor, if there was no decent database interfaces I could survive in command line and if there were no Apple Mac's I could even survive on Windows but I wouldn't survive very long without version control. Version control is the first and last thing I check when developing a new feature or making bug fixes, in fact my whole workflow revolves around it.

I'm not here to convince you that you should be using some kind of version control, there's really no argument for not using it. What I want to do is go through the biggest improvements I found when I switched from SVN (Subversion) to GIT. I was a long time user of SVN and lived with the pitfalls for far to long, but don't get me wrong switching from SVN to GIT was a struggle, and yes I questioned what the hell I was doing and if it really was worth it. But after a good six months of using GIT I can confirm the struggle is most definitely worth it. And here's why:

1. Proper Branching.

GIT is really all about branching, SVN could do branching but its not a great implementation and it's pretty much discouraged unless you are making a huge change. SVN was a nightmare if you were going to take more then a few hours developing a feature, and whilst making that development you live in fear of a bug or a issue arising which had nothing to do with your feature. With branching in GIT you just create a new branch for your feature, if anything comes up in between you just create a new branch from your master for your bug fix, then either roll it out straight away or merge with your feature and deploy it all together. The flexibility of GIT makes your ad-hoc and long-term workflow really smooth and consistent.

2. Easier rollbacks.

Let's say you just worked on a feature, committed and deployed it and went home for the day, then you get a call at 2 in the morning because something has gone wrong and now you have to rollback to an old commit. SVN doesn't offer much to help you rollback quickly only a reverse merge which brings up the dreaded diff tool but GIT makes this really easy, with a built in rollback feature you can literally select the last known working commit and rollback, you can also cherry pick the broken features straight from the files to get you back to a working state extremely quickly.

3. Your choice of workflow, staging and master.

I love having a predefined workflow for developing and deploying changes. I currently use two main remote branches, a master which is basically the live site and known working version and a staging branch for developments which is for testing before pushing to the master, I also have a number of ad-hoc development branches on my remote which is for long term developments and sharing with colleagues. With GIT I can make my changes in a new branch, merge the changes into a staging branch which I have setup to auto-deploy to the staging server to test and check the features. Then when happy merge and push to the master branch and manually deploy to the live server. The workflow takes out all the guess work and that edge of the seat feeling that you get when deploying to a live server.

4. Work better with colleagues.

Version control in general makes it easy to work with colleagues but GIT takes it to the next level. There are endless options for workflows, you could simply have a remote branch that you share or you could setup sub teams which are all working on features in there own right, GIT makes the process of segregating jobs into teams and merging files into a central branch straight forward and easy for everyone to understand. It also makes open source projects nice and easy to manage, Github and Bit Bucket both use GIT, anyone can checkout a project, make a change and request a pull into the master. More info about working with GIT in a team can be found here.

5. GIT managed deployments.

Although not actually part of GIT, the whole workflow allows for much cleaner deployments. If you have been managing deployments through FTP then you will probably know that keeping track of the files that need to be uploaded or deleted can be a nightmare, and once uploaded you always have that slight fear that you missed something. Most GIT remote hosts (Github, Bit Bucket, Beanstalk) allow you deploy automatically or manually based on the branch you have pushed too, for instants you might wanting your staging branch to upload to your staging server and your master to upload to the live server, if you wanted to get really hardcore you could install GIT on your server and then pull the changes directly onto the server. Deploying this way makes sure that all the files are being deployed plus most hosts also have a roll-back switch in case something went wrong.

So there you have it I'm a GIT convert and I strongly recommend that you give it a try if you haven't already.