Version control is a sine qua non of serious software development, but casual developers and even non-programmers can use it to improve their lives. In its simplest form, a version control tool maintains an archive of the history of a project — not just its current state, but every milestone along the way. So if you realize that the progress you’ve made in the last three weeks is all wrong, you can effortlessly go back to what you had then; or just glance at it and harvest the good parts.
Version Control Options
Git is a relative upstart, but it has some advantages that set it apart. It’s a distributed system, like some others, meaning that everyone who works on a project has a complete local copy of the project and its history. In Subversion, contrarily, there’s just one a single centralized complete copy. Git is also wildly fast, because it’s written in C — and written by Linus Torvalds, who is about as close as the software world gets to a celebrity. In practical terms, that means that it’s been eagerly adopted by the Linux fanbase, and its development is accordingly swift.
Git at present is best used and installed from the command line. Download the source code from the Git site, unzip it, and install it according to the instructions in the package. Users of Debian, Fedora, and Windows can make use of pre-compiled binary packages — on Cygwin if you’re on Windows.
Tip: This is a good guide for building Git on a Mac. I had to use the line “export NO_MSGFMT=1″ before “make all”.
At the command line, go to the directory where the project you want to version-control lives (or will live if it hasn’t yet been begun).
Git will create a new subdirectory called .git and tell you “Initialized empty Git repository in .git/”.
Next, tell Git about all the files in the directory:
git add .
The dot represents the entire directory.
Then it’s time for your first commit — the process of taking a snapshot of the state of the project and putting it into Git’s repository. This is done with git commit. It’ll pop you into your default text editor to type a description of the commit. Something like “My initial commit” should be fine.
That’s all it takes to start a Git repository. You can create different ones for different projects, as many as you like.
git add <filenames> followed by git commit updates the repository with a new version of the project (keeping the old one stored, of course), or git commit -a will automatically commit any changes you’ve made to existing files, but not include any new files you’ve created.
git log shows all the commits you’ve made, each tagged with a 40-character unique name like 0b1016862478c628f9c22d2fb3da24d5f6c066a6. To change all the files in the directory to what they were as of that commit, type:
git checkout 0b1016862478c628f9c22d2fb3da24d5f6c066a6
or just enough of the name to be distinctive:
git checkout 0b1016
should be fine. To return to the latest version
git checkout HEAD
If you are working on the project by yourself with only one computer, that’s enough to get started, although there are all kinds of extra features we haven’t touched on. If you’re collaborating, there are a few more cool tools.
Running this command:
git clone ssh://<login>@<hostname>/<git directory>
on another computer will create an exact copy of your repository on that machine. The two developers can work independently, running git fetch <URL> to retrieve the latest version from the other machine. This is extensible to as many machines as you like. git push <URL> does the reverse, sending your latest commits to the specified repository.
- Webmonkey has a tutorial on getting started with CVS
- cworth.org has an excellent introduction
- Smalltalk’s Using Git Without Feeling Stupid is another