I've seen a number of questions/blog posts about setting up a Git repository with Drupal Core and Contrib Modules as submodules, such as Setting up the ideal multiple repository Drupal Site version control with a DVCS.

What advantages do you get from this kind of repository set up?
Many people say things like "core and module updates are really easy," but what makes this approach easier/better than have a single repository containing everything for the site and using Drush to update Core and Contrib, then committing back to your repository?
I can see this being great for contributing to those projects since each module is a separate repository, but what benefits does to provide when focusing on building your own site?

2 Answers 2


At our workplace we avoid git submodules as they add unneccessary complexity to the system.

We run one git repo for each site, and we have drupal core as an upstream remote. This makes merging in 7.12 for example as easy as:

  • git fetch upstream
  • git merge 7.12

As for contrib, drush is king

  • drush dl views
  • git add -A
  • git commit -m 'bumps views to next stable'

Hope this helps

  • What advantage you get get from having Drupal Core set up as an upstream remote? Why merge in Core changes instead of using Drush for that as well?
    – Chaulky
    Commented Feb 9, 2012 at 21:30
  • 1
    Full git history is the main reason (back to Dries first commit). Yes you can use drush to update core, just like you can use tar balls. We prefer git.
    – wiifm
    Commented Feb 10, 2012 at 1:05

Here are some of the advantages of using Git submodules with Drupal:

  1. 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.
  2. 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.
  3. 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.
  • These are reasonably good advantages, but I must disagree with your first one. There's no need to manually download and unpack module updates. You should be using Drush for this which requires one command to download, unpack, and run all required update hooks.
    – Chaulky
    Commented Oct 21, 2013 at 19:52
  • 1
    True. My point was basically that you can't simply pull in updates with Git; you need the entire module. Drush definitely makes this process easier, but I didn't want to confuse folks who aren't comfortable with Drush.
    – colan
    Commented Oct 22, 2013 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.