Subversion Is An Old Man's Tool.

As Joel Spolsky put it: "Distributed Version Control is here to stay, baby”. If you've read Joel's stuff, you know he has a way of making sense — a quality of writing which can be tough to find on the Internet. As a Git user, I can't say Joel converted me, but he did get me thinking about why I too hung on to familiar ol' Subversion long after it's obsolescence. Rather than boring you with that, herein lies a minimalist guide to getting started with distributed version control.

If you are wondering about the Git vs Mercurial (Hg) debate, don't bother. Both work well and can even be used in tandem. The focus here will be on Git because it has alphabetical priority, and Joel has already written Hg Init: a Mercurial tutorial.

For experienced developers, the hardest part about learning Git is unlearning Subversion or other legacy VCS. Here are a few things to keep in mind (if you get bored, just substitute "jedi" for "repository"):

• Any repository can be cloned.


• Any repository can be a master.


• Distributed VCS doesn't mandate distribution.


• Local changes: checkout, commit


• Remote changes: pull, push

A New Repository

Don't be put off the 'distributed' bit, git is perfectly happy to have just one folder — repository and working copy all rolled into one:

mkdir /srv/git/foo
cd /srv/git/foo
git init
# add some files
git add .
git commit -m'initial checkin'

So Git scales down nicely, but with shared repositories it is important to know that Git will grouse if asked to push changes to a destination where files are checked out. This problem is easily avoided with a bare repository, essentially a repository which cannot have files checked out locally:

mkdir /srv/git/foo
cd /srv/git/foo
git --bare init

Send in the Clones

Where git repositories already exist, new ones can be cloned; optionally, the new clone can be --bare:

# new working copy:
git clone ssh://user@gitserver/srv/git/foo
git pull

# bare clone:
git clone --bare ssh://user@gitserver/srv/git/foo
git pull

Go with the Workflow

Much of the Git workflow is straightforward, especially if your working copy was cloned from a (bare) master repository:

# get the latest changes
git pull

# make some changes
find . -type f -exec dd if=/dev/zero of={} count=1 \;

# oh crap! I just (sort of) Zeroed all my files
# no worries, just abandon the changes

git checkout .

# double check
git status

# make changes worth keeping
# ... then commit
git commit -a

# need to amend the last check-in message?
git commit --amend

# push local changes to master
git push

There's enough to jump in and get into trouble with git; to find out more, try the following resources:

• Git Documentation
• Git Tools & Hosting


• Why is it called "git"?