Learn git right for a long and happy life

Git – love – hate

I’ve used git now for a long time. I think it is a masterpiece of design, I use it all day every day and I can’t imagine what it would be like not to use it. So, no question, I love git.

As y’all may know, Linus Torvalds wrote git from scratch. He loves it too. Here is Linus talking about git in a question and answer session:

Actually I’m proud of git. I want to say this. The fact that I had to write git was accidental, but Linux, the design came from a great mind, and that great mind was not mine. I mean you have to give credit for the design of Linux to Kernighan and Ritchie and Thompson. I mean there’s a reason I like Unix and I wanted to redo it. I do want to say that git is a design that is mine and unique, and I’m proud of the fact that I can damn well also do good design from scratch.

But some people hate git. Really hate it. They find it confusing and error prone and it makes them angry. Why are there such different views?

I think the reason some people hate git, is because they don’t yet understand it. The reason I can say this without being patronizing is because I went through the same thing myself.

When I first started using git, I found it uncomfortable. I could see it was very powerful, but I sometimes got lost and stuck and had to Google for a set of magic commands to get me out of trouble. I once accidentally made a huge mess of our project’s main repository by running a command I didn’t understand. Git often made me feel stupid. It felt like a prototype race car with a badly designed dashboard that I couldn’t control, and that was about to take me off the road, possibly at very high speed.

Then, one day, I read the git parable. The git parable is a little story about a developer trying to work out how to make a version control system. It gradually builds up from copying whole directories of files to something very much like git. I didn’t understand it all right away, but as soon as I read that page, the light-bulb went on – I got git. At once I started to feel comfortable. I knew that I could work out why git worked the way it did. I could see that it must be possible to do complicated and powerful things, and I could work out how to do them.

Reading the git parable took me about 45 minutes, but those 45 minutes changed me from an unhappy git user to someone who uses git often every day, but, happily, knowing that I have the right tool for the job.

So, my experience tells me that to use git – yes use git – you need to spend the short amount of time it takes to understand git. You don’t believe me, or you think that I’m a strange kind of person not like you who probably likes writing their own operating systems. Not so - the insight I’m describing comes up over and over. From the git parable:

Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying. Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land.

From understanding git conceptually:

When I first started using Git, I read plenty of tutorials, as well as the user manual. Though I picked up the basic usage patterns and commands, I never felt like I grasped what was going on “under the hood,” so to speak. Frequently this resulted in cryptic error messages, caused by my random guessing at the right command to use at a given time. These difficulties worsened as I began to need more advanced (and less well documented) features.

Here’s a quote from the pro git book by Scott Chacon. The git book is a standard reference that is hosted on the main git website.

Chapter 9: Git Internals

You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book – in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners. Thus, I’ve made this discussion the last chapter in the book so you could read it early or later in your learning process. I leave it up to you to decide.

Of course it would be easier if you didn’t need the deep shit – but if you want to spend the least time suffering from git, and the most time enjoying it, then you do need the deep shit. Luckily the deep shit isn’t that deep. When you have got to the bottom of it, I’m betting that you’ll agree that the alchemist has succeeded at last, and the – er – lead has finally turned into gold.

So – please – invest an hour and a half of your life to understand this stuff. Concentrate, go slowly, make sure you get it. In return for 90 minutes you will get many happy years for which git will appear in its true form, both beautiful and useful.

The one thing about git you really need to understand

git is not really a “Version Control System”. It is better described as a “Content Management System”, that turns out to be really good for version control.

I’ll say that again. Git is a content management system. To quote from the root page of the git manual: “git - the stupid content tracker”.

The reason that this is important is that git thinks in a very simple way about files and directories. You will ask git to keep snapshots of files in a directory, and it does just this; it stores snapshots of the files, so you can go back to them later.

Now you know that actual fact, you are ready to read A curious tale.