As a followup to my Drupal/Git workflow post, many people have asked about using Git Flow on a Drupal project. I've successfully adopted Git Flow for my projects. Here's how I did it:
Prerequisites
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:
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:
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:
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.
Updating core
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...
git submodule/subtree
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!
Comments
David King (not verified) says:
Instead of committing all the code for core and contrib to your git repo, you can just use a drush make file to declare what pieces you want in your site. Then you just run drush make to rebuild your site when there are changes (new version, module, theme, or patch). Core and contrib modules are already tracked on d.o. No reason to duplicate that. One great aspect of drush make files is that they are self-documenting with regards to versions and applied patches. You also won't have to deal with the messiness of git submodules.
cweagans says:
I think you may have missed the point. This way gives you the full history for all of the core files, which is a huge help, IMO.
Add new comment