On Tuesday 09 September 2008 23:53:24 Ryan Cross wrote:
I have a client that really wants to use GIT to manage their code. So, if anyone would like to chime in with non-svn development workflows/organization that would be great too.
There are really an _enormous_ number of different ways one can use git to manage a drupal project, but the right implementation with git would be highly dependent on your client's workflow. For example, I've made my local development environment into something of a git proof-of-concept: I regularly rsync off of cvs.drupal.org to provide a local mirror (for speed purposes), pull those into git repos using git- cvsimport, then push them into bare git repos that I also maintain locally (I've yet to find just the right mojo to get git-cvsimport to interact directly with bare git repos). I do this for both contrib and core. Then, I structure out individual drupal installs using git subprojects, wherein each drupal module retains the remote reference to the appropriate location within the contrib repo, so it can automatically be aware of and gobble up any upstream changes. I can also make small tweaks to a particular install on a new branch, or I can also pop off a new branch if I'm looking to set up a new site with a slightly different configuration. Most of that is utter and complete overkill for only one machine (as I said, proof of concept!), but the place where it gets nifty is the push/pulling between my laptop and desktop. It's getting to easy to keep the two synced up in all the right ways that I find myself forgetting which machine I made a given change on - then laughing as I `git pull` and remember that it doesn't matter :) However, that kind of a setup probably wouldn't be much use for a single site. If your client is really gung-ho about using git, and they're sufficiently familiar with using git on the command line, AND there are a few folks who'll be working on the site simultaneously, I'd personally recommend pulling down as much of the necessary code via drush as possible to your dev server, then setting up each developer with access to the dev server's git repo; clone off of that, then let people push/pull to each other and the dev server basically willy nilly (git is largely capable of taking care of the details, barring big sticky conflicts) until you're ready to push out to live. From there, it starts getting more complicated, and into questions about deployment. And on that...
I'm also curious if people would expand a bit more about how they manage their DB changes. It sounds like angie/lullabot store a DB dump in the repository and then upload that with their deployment. Is this standard practice for other people?
You should probably have a looksee at last months' discussion: http://lists.drupal.org/pipermail/development/2008-August/030745.html
-Ryan
cheers, Sam