Jason Blevis describes my thoughts quite precisely when we 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
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
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?
git initinitializes a new repository in the current directory. A directory called
.gitis created and populated with all sorts of magic files in it. Don't touch those unless you want to break things.
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 *.htmlinstead.
git commitcreates 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://firstname.lastname@example.org/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.
- Git by example
- Publishing git repositories
- Organizing multiple git respositories
- Setting up a new remote git repository
- Managing Websites with Git
- Ikiwiki is a Wiki with a Git back-end. It is written in Perl, and you can do some pretty cool things with it, such as taking a copy of your wiki along with you.
- ViewGit is a lightweight PHP app that allows me to view my repositories in a Web browser.