Topics: 

• Drupal Planet
• Revision Control
• Configuration Management
• Presentations

Several months ago, I ran a session on the subject at DrupalCamp Montreal. I educated attendees on how Git submodules can be used with Drupal to take advantage of some Git features that wouldn't otherwise be realized.

Here are the benefits of the approach (as discussed on Drupal Answers):

• You can git fetch/merge/pull updates for your contributed modules directly from Drupal.org. There is no need to manually download a new version of each, unpack and then commit (or do this with Drush).
• You can see upstream version history in your own Git log. This makes it easy to see where you're at; you can check if you've got specific upstream commits. Otherwise, all you can see are local changes and "Upgraded Blah from 2.3 to 2.4." log messages.
• You don't need to reapply (cherry-pick) custom changes to your contributed modules after upgrading them. If you use the one-Git-repository method, each contributed-module upgrade will overwrite anything you're previously patched and committed. This is a huge problem because developers often forget to do the reapplying, and then you're left with resolved issues that have been reverted. If you're using submodules, you simply maintain a custom branch, and merge upstream tags (or commit IDs) into it.

Randy Fay essentially wrote the bible on the practice in 2011, and there was even a Drupal on Git initiative with the community to standardize it. But although there are clear benefits, Git submodules within the Drupal space aren't overly popular. I do have a client who's using them, but generally, developers often work with a single repository. (Drush makefiles are still being used, but less so.)

While great in theory, the problem is that it adds more moving parts to existing development processes. I find that if can be difficult enough getting developers to follow all prescribed devops directives. Adding to the mix increases the risk of breakage and further problems. So keeping things simple, with only one (1) repository, isn't a bad plan.

I'll admit that I generally stick with the single-repository approach myself, mostly because I work with developers I'd rather not confuse, and most (if not all) of the Drupal-specific hosting providers are only set up to support projects set up that way.

It's worth noting that there is now an alternative, Git Subtree. For a general overview, take a look at Alternatives To Git Submodule: Git Subtree, or Smarter Drupal projects in projects management with git-subtree for information on how it works with Drupal specifically. I haven't tried this (yet) for any projects, but if I hear enough good things about it, I'll take it for a spin.

See the attached file for my slides, and the YouTube video for the presentation itself. I apologize for the less-than-stellar audio quality. I wasn't given a microphone; we only had access to the one on the camera.

File(s): Maximizing version control: Manage your Drupal project with Git submodules.pdf