Jason Blevis describes my thoughts quite precisely when he wrote:

It’s hard to leave behind the comfort of a system that you are very familiar with, especially when you think about the time you’ll spend pouring through manpages to do even the simplest thing in the new system. That was exactly the mental block that kept me from trying Git for so long. I’ve been learning to use it lately and I’ve become a complete convert.

Git is a version control system designed by Linus Torvalds. Even though Linus uses Git to manage the Linux project, you don’t have to understand how the Linux project works to use Git: you can start off as I did, using Git for basic stuff like for a small software project or a Web site.

If you’ve previously worked with other revision control systems such as CVS or SVN, you are in for a surprise: Git is quite different. Get your hands dirty with a quick rundown over Git’s commands if you want to, now, with Git for the lazy.

Git is no more difficult than mkdir and scp. Don’t be taken aback by the huge number of commands that Git has: to start with, we need only a handful of those. Use Git even if you only have a single machine: it has saved my venerable behind more than once.

Git’s documentation is good, and what I like most is that it brings along good old Unix manual pages, which I can view with man or with git help command. If you prefer reading old-fashioned paper, a good overview can be found in Pragmatic Version Control using Git by Travis Swicegood.

Starting with a small project

Assume you have a server at your disposal which is accessible over SSH (preferably with public keys – they make your life safe and easy). Assume further, that this server is called tig.example.com. (I like giving my machines meaningful names – tig is Git spelled backwards.) You also have a laptop or a workstation on which you do most of your work. I’ll call mine lap.example.com.

Let’s further assume we are working on a book, a small program, a set of related configuration files, or a static Web site. If you are like I, you keep these files in a single directory on your laptop and periodically synchronize this with the server for purposes of backing up your changes as well as to get the files to the target system (i.e. the server).

On the server …

Let’s make things easy: our “primary” data is on the server, so we log into the server, and change into our project directory:

tig$ cd $project
tig$ git init
tig$ git add .      # note the period indicating current directory
tig$ git commit -m "First backup -- boy, was that hard!"

Congratulations: you have your first Git repository. What happened?

  1. git init initializes a new repository in the current directory. A directory called .git is created and populated with all sorts of magic files in it. Don’t touch those unless you want to break things.
  2. With git add . we told git to add all files (recursively) from the current directory. If we’d only wanted to track HTML files, we could have specified git add *.html instead.
  3. git commit creates a first commit and sets the modification message to what we specified.

On the laptop …

It is late, and I want to go home. On the long train ride home, I want to continue working on my project. I take a copy of the project’s repository along with me.

lap$ cd $HOME
lap$ git clone ssh://jpm@tig.example.com/project
lap$ cd project
lap$ ...

That is it. I now have the full repository (everything that was committed at the time of creating the clone) on my laptop.

I can now edit files to my hearts content, whilst on the road. Not only that though: I can also add files (git add), remove them (git rm), I can make commits while I’m disconnected (git commit), etc.

Whenever I get back, or whenever I want to synchronize my work with the repository on the server, I push the repository (including whatever I’ve committed to date) back to the server.

lap$ cd $HOME/project
lap$ git push

Voila. Ain’t that sweet? I did say above, that Git is quite different from revision control systems you already know.

Further reading:

Linux, Apache, MacOSX, CLI, and Backup :: 08 Mar 2009 :: e-mail