Revision Control with Git, Part 1

Follow along as I learn all about Git, a revision control system, and begin implementing it for all our company’s projects, on the Windows operating system.

This is the first installment of the series.

Up until now, we’ve been using subversion as (centralized) revision control system – a.k.a version control, source control or source code management, together with TortoiseSVN as we’re on Windows.

I knew that we weren’t using subversion correctly, as we had never once created a branch. Shocking, I know. But we had more important things to spend our time on, and the way we had been using it was enough for then. So I recently started looking into how to use subversion properly. I was looking around for other solutions as well, especially as subversion is pretty darn slow. Which ultimately led me to Git, a very popular distributed (in contrast to centralized) revision control system created by Linus Torvalds, the Jedi behind Linux.

Why Git?

There are a load of reasons I could think of for personally wanting to switch to a distributed system:

Working offline / locally
As we sometimes work from somewhere with no internet connectivity (which is the office at times, due to South Africa’s inconsistent internet availability!), and as I would like to be able to do so more and more (read “travel”), a mature solution (like Git), which operates well even without an umbilical internet connection, is necessary.

Speed
Though we love coffee, drinking a cup each time you’re yet again waiting for a commit to finish, isn’t healthy. And there’s a terrible vibe in the office when something forces a programmer to take a break from coding when they’ve got that juggernaut momentum going — it’s bad for them, and for their productivity. But Git is really fast — it can almost keep up with our programmers!

Flexible workflows
We work on quite a number of different projects, with different management setups for each project, so need flexibility in how the project workflow is managed. Sometimes I’d work on a project by myself so just need a centralized-style workflow, but at other times a number of us work as a team, and somebody — a different person each time — has to be in control, to manage which changes or features become part of the main project. With Git, this is easy. (For when I am in charge, I’ve started looking into the Dictator workflow, mmwhahahaa. But more on that later..)

More great reasons for using Git, as well as reasons for using specifically Git rather than some other popular system, can be found at Why Git is Better than X.

That’s it for Part 1. But don’t despair, Part 2 is available!

Leave a Reply