I’ve been meaning to look at Git for yonks (though, as I write this, I can’t help but wonder how long one yonk is). It turns out that there are more Git introductions on the web than most people have had hot dinners, so to differentiate it, I’ll try to make mine titchy.
So, here we go. Git keeps the repository in the same folder as the project being tracked; this is quite different to Subversion, which requires the repo to be in a different location. Git’s approach is a bonus, since it means that commits can be made even if a network repo is unavailable, as can be the case with svn.
I’ll assume that git is installed (type git –version to check). To initialise a Git repo, do this:
cd /Users/jon/Myproject # cd to your project git init # Creates a new Git repo git config user.name "Firstname Lastname" # Set your details to label commits git config user.email "firstname.lastname@example.org" # Use git config --global if # you wish to set them for all projects git config core.editor "nano" # Avoid the torture that is vi!
Magic. Okay, if all that went well, we can start adding the files in the project. To add them all, do this:
git add .
This works recursively, so will add the whole project. You can of course specify folders or paths instead of the dot, though sadly there doesn’t appear to be an option for it to operate non-recursively. Since there are a number of files in my (symfony) project I don’t wish to track, I “unadded” them thusly:
git rm --cached cache/* git rm --cached log/* git rm --cached files/*
A good discussion on that is here.
To make an initial commit, type the following:
This will drop you into the editor specified earlier. In general, there is a convention to summarise the changes on line 1, add a CR on line 2, then write lengthy prose from line 3. This allows the commit message to be split into the subject/body of an email – though whether I’ll get out of the Subversion habit of “short message (see #ticket)” is currently in doubt!
An important point with Git is that modified files are not automatic candidates for committing – they also need to be added. I quite like this – I often am working on a change, and then an urgent bug comes in and I have to switch to fixing that. This results in two sets of changes that need to be committed separately – and in Subversion using “svn commit” will commit them all. Of course, one can specify paths and files with Subversion, but it is fiddly and prone to missing something off.
To see the current status of a Git repo, use:
This will let you know what will be committed on the next commit (“Changes to be committed”), what has changed but has not yet been added to the next commit (“Changes not staged for commit”) and files that have not yet been added to the repo (“Untracked files”).
Final note: setting up files and folders to ignore is arguably easier in Git than Subversion. Just create a file called “.gitignore” in the root, and add to it the paths you don’t want tracked at all. Here’s mine:
# Normal files/folders to ignore cache/* files/* log/* # Any IDE folders to ignore nbproject
There – easy! If any reader wants to know more, they could do worse than starting here.