Setting up gitThere are many tutorials for setting up git, but the one that seems to be the most straight forward is github's tutorial http://help.github.com/set-up-git-redirect Even if you're not using GitHub, the instructions are pretty easy to follow. If you're not using Github, you can skip steps like: "4. Add your SSH key to GitHub" however, having a github account is not a bad thing, so when it doubt follow all of the steps and you'll still be ready to git.
Keeping a site under gitSince I generally use Drupal multisites and don't kill kittens, I will keep each drupal_root/sites/
Get git startedIf you're building a site from scratch and there is no existing repository, create the basics of the site (files directory, settings.php, etc.) and then create your git repo.
Depending on how you're going to be using the version control, you may or may not want to have your
cd ~/Sites/drupal/sites; mkdir subsite.vmdev; mkdir subsite.vmdev/files; cp default/default.settings.php subsite.vmdev/settings.php
files directory controlled. Typically those are user uploaded files and site specific and don't need to be transferred if you're using git as part of a deployment strategy.
Also, I almost never keep settings.php in the repository so that you don't ever accidentally spread your database username and password around. Luckily git provides an easy way for us to ask git to ignore certain files/folders. If you create a file named
.gitignore (the leading dot is important), then you can write out file names or patterns that you would like to have excluded from the repository.
Now that you have the files for a working Drupal site, you can initialize your git repository.
echo "settings.php" > .gitignore echo "files/" >> .gitignore
That's it. Now you have a completely functional, albeit empty repository ready for action.
Using git in the building processOnce you've started downloading contrib modules, themes, and libraries, and creating your subtheme and custom modules, your directory structure will start changing. How often you update your git repository is a very personal choice. There are those who "commit early, commit often" which leads to great history and identifiability for all things and there are those who commit only when they're ready to share their code. As with most things, my preferred method is somewhere in the middle. To commit changes to your repository, you need to stage which changes you'd like to commit and then write a single commit for them. Typically, I will commit when a) adding a cohesive set of modules, b) finishing an individual task, or c) fixing a quick bug. So, one example would be when I get "calendar" set up.
If I had an existing custom module
mkdir modules/contrib drush dl calendar, date, views, jquery_ui git add modules/contrib/calendar modules/contrib/date modules/contrib/views modules/contrib/jquery_ui git commit -m "Downloaded calendar and necessary modules (date, views, jquery_ui)"
subsite_fixes and had finished writing the code that incorporated a custom block, I might do the following:
A "task" might incorporate changes to more than one file. There may be CSS changes, PHP changes and exports that need to be updated. Those can all be done in a single commit as long as they're all related. Next up: Sharing your git repositories
git add modules/custom/subsite_fixes/ git commit -m "Updated to incorporate new strategic block"