An Introduction to git
I’m going to write an introduction to one of my favourite tools, git. This will not be a how-to, cheat-sheet, or any kind of manual of how to use git, there are plenty of those around. I will not even list a single git command. Instead I will explain a bit what git is, and how it works.
Git is a distributed revision control system. This means that you can use it to keep track of revisions, or versions of things you work on. The distributed part means that git is not dependent on a central repository like many other revision control systems, but each copy of the repository is a full, independent repository. Different repositories can of course be chained together as you see fit.
Git was originally designed by Linus Torvalds for managing the Linux kernel source code. git is a quite technical tool, but there are graphical applications that might make it easier to use if you are not comfortable with the command line. In my experience though, as you learn the system you tend to use the command line more and more. It’s the most flexible and powerful way to use the software.
I’m going to go a bit into how the software works, because it’s useful to know. The basic idea of git is that you keep track of all changes you make in a directory structure that holds your project, or part of your project. Git basically makes a copy of all your files, and stores them in a hidden directory. They are named by the hash of the entire file, this, means that two identical files are named the same, and if there are any differences between the files they never have the same file-name. The directory structure is stored separately, and only contain links to the hash values of the files. This means that snapshots of your project take relatively little space.
Git supports branching, so you can work on many versions of the project at the same time. Branches can then be merged back into each other, or specific files can be copied onto other branches. Another useful feature is that the snapshots hash values contains the hash value of the previous snapshot, this means that there is an unbroken chain to the first snapshot, if anyone ever changes a single byte anywhere in the work history, the values won’t match. So you can be sure that everyone is working with an identical copy of the project.
The part that I found hardest when starting out with git is the question of why you should use it. Especially if you are working alone on your projects, it might seem like a lot of extra hassle for little or no gain. But I have found that using git changes the way you work for the better. One example that all coders probably will find familiar is commenting out code when you don’t use it, because you figure it might be useful later. This can quickly lead to quite unmanageable code. When you are using git you can safely delete the portion that you no longer use. If you ever need it later, you can just go back in your revision history and look up the code.
Git is designed for tracking software source code, but it can be used for most types of projects. It is most useful when working with multiple files, and the merge tools only work with text files, but it can be used for most project management. It can be a bit tricky to learn, but if you are serious about programming, or working with html, or other text based projects, git really is an essential tool along with ssh or an editor or IDE.