Managing Drupal projects with Git Flow
While you can use Git Flow with the stock Git commands (git branch, git merge, etc.), I find that it's much more pleasant to use the Git Flow extensions. There are already detailed installation instructions, so I won't duplicate them here.
Knowledge of how Git Flow works is also recommended (you won't get much benefit out of this setup unless you know how things are set up). There's a wonderful screencast produced by Dave Bock from Code Sherpas that outlines all of the mechanics of Git Flow, so I won't attempt to duplicate that either.
Initial project setup
To start off, open a terminal to where you want your project root to be and run:
git init git flow init
This will initialize your Git repository and then create all of the branches needed for Git Flow. You can usually just answer all of the Git Flow questions with the default answers.
Next, we'll add the Drupal Core remote to the repository and download all of the history (this just fetches the history, but doesn't actually do anything with it just yet):
git remote add core git://drupalcode.org/project/drupal.git git fetch core
git flow init should have already checked out the
develop branch, but if, for some reason, that is not the case, go ahead and check out the
develop branch now:
git checkout develop
Now that we've pulled in all of Core's history and we're on the
develop branch, we need to merge the most recent version of Drupal into the develop branch (created by Git Flow). As of this writing, the most recent stable release is Drupal 7.16:
git merge 7.16
This will prompt you for a commit message. I usually just leave it alone, but if you're picky about your commit messages, you can change it.
At this point, we have a fresh copy of Drupal 7.16 in a Git Flow setup.
At some point, you'll (hopefully) update Drupal Core. In this setup, it's as easy as:
git checkout develop # Replace the tag name below with the new release tag name git merge 7.17
Caveat: If another developer clones from your project repository, and that developer wants to merge core updates, they will have to add the core remote and fetch the history, as we did above.
Contrib module/theme management
I have not settled on a single workflow for bringing contrib code into my projects. There's two that sort of stand out to me, and they both have their pros and cons:
Just commit the code
This method is nice because you don't have to do anything special. Just download the code, drop it into place, and commit it. No muss, no fuss. If you ever need to patch contrib code, you can just commit it (and hopefully document that patch somewhere).
The downside to this approach is that
git blame becomes kind of useless for figuring out why contrib modules work the way they do, and instead can only be used for figuring out when the module changed within the scope of your project. Some people would see this as a plus, but I think that having a nice, complete history around all of the code in a project is a huge help, which is why you would use...
I admit that I haven't played with subtree as much as I probably should, but I do know that
git submodule is quite handy for pulling in contrib code.
The problem with using
git submodule is that patching contrib modules becomes very difficult -- essentially, you have to create a separate remote where you store your customizations. This becomes very tedious when you have many modules with patches applied. If you want to go this route, there's a pretty nice guide for dealing with contrib code with submodules.
Generally, I just commit the code. It's a lot easier to manage, in my opinion, and while I'm not able to fully utilize
git blame, I can always just open drupalcode.org and check out the history that way.
Have any suggestions for how to improve this workflow? I'd love to hear them in the comments!