Git. The trendy source control management system. Like many other of my peers, I’ve been using GitHub for a while (for personal projects, in my case). For the longest time, however, I felt like the only person in the world that didn’t get it; it never felt natural for me, or superior in any way to what I was already using (Subversion).

It’s not that I didn’t learn about it. I’ve done my research. I’ve read some tutorials. I did learn how to use it and how to do the basics – commit and checkout files. But after that, I felt a disconnect, as if it never made any sense, and as if everything was more complicated than it needed to be. I ended up using the Git graphical user interface for everything, and still that was too much effort. It’s not that I don’t line command-line interfaces; it’s that it just seemed more complicated than it should be, and Linus Torvalds being Linus Torvalds didn’t offer a pragmatic enough explanation to what I was missing from it.

It’s only a few days ago that I decided to give up all the knowledge I had about Git and start from scratch, reading from the basics – not just command-line tutorials, mind you, but the more in-depth explanations. And boy. After sitting down and really focusing on it, does it make sense.

I do get it now. You see, the problem with learning Git is that a lot of websites out there tell you what Git is, and how to use it. What they don’t tell you is what Git is not.

The root of the problem for me was that I have been a Subversion (and CVS) user for a very long time. Because of that, when I heard about Git, I didn’t see it as a new system. I saw it as new version of something that was Subversion-like in functionality.

And that’s precisely what Git is not.

The way I see it (now at least), Git is a glorified way to handle local folders with copies of different versions of your files. It’s a collection of command-line tools that manage backup folders. And, in doing that, it can also occasionally, maybe, connect to a server to send your stuff there. And that’s all very good.

This is, of course, because of certain philosophical decisions that were made during Git’s engineering that go straight against the design of tools like Subversion and CVS. The idea of using a distributed version control system, maybe especially one like Git, is that you should have the repository, instead of connecting to it on a remote server.

And while I knew that Git had its own local repository, I never quite understood this: the local version is not a simplified version of a remote repository, for convenience or speed’s sake. It’s the actual thing (but, of course, you can connect to other repositories to push and fetch things so two or more people can have the same content in their own repository).

Overall, because of my experience with Subversion, there were certain paradigms and expectations I had to erase from memory before I could successfully understand, and really use, Git. The whole point is that if you come from Subversion, CVS, or a similar system, you have to unlearn what you know before you can use Git.

Which brings me to the second part of this post. There’s a certain order of things I’d recommend for anyone trying to learn Git, especially anyone coming from other source control management systems.

First of all, I don’t recommend reading tutorials that start with the commands and nothing more. These are the kind of tutorials that are written by the kind of people that don’t get it – they think Git will feel natural for everyone just because it feels natural for them. But the thing is, learning a syntax is easy; there are plenty quick references available for commands. The more important thing, however, is understanding why the commands work the way they work, so it’ll feel natural when you have to use them.

First, read Aha! Moments when learning Git. You don’t have to give it a lot of thought, or make notes of the commands; just glancing over the key points is what’s important here.

Then, especially if you come from Subversion or similar systems, read Git is Simpler Than You Think. Again, no need to go deep into this if you’re not ready yet, but this is a great read and draws a great parallel with my own story. It makes some especially accurate points. For example:

“Ultimately, when you look at Git, you don’t see a product that was “designed” holistically. It’s more like a collection of command-line utilities.”

After that, you’re probably ready to actually learn how to use Git. Perhaps not surprisingly, GitHub has a series of tutorials (in 6 short lessons) that explain the whys and hows of the system (in video and text format, with some overlap between the two). Start with Introduction to Git and then follow along. GitHub has, for some reason, deleted their short introductory tutorials. In its absence, their training website has some interesting resources.

Then it will all make sense. Including using the command line. Because, to be honest, some of the features behind Git are so abstract that I hardly think they could be effectively used by a GUI application anyway (to my surprise, I started a new personal project over the weekend and didn’t feel the need to use the GUI even once).

Finally, if you’re so inclined, Understanding Git Conceptually is also a great follow-up read. And, of course, the official documentation is pretty good (if very wordy). It also includes a free book for users that want some more advanced knowledge.

The Emperor doth have clothes. It’s just made of a different fabric than you’ve learned to expect.