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.
"Drush makefiles are still
"Drush makefiles are still being used, but less so."
Can you please elaborate a little more on that. Maybe I misunderstood, but isn't the use case for Drush makefiles (automate initial Drupal project setup/installation) different from what you are talking about? How are they relevant here?
Also, since I've been spending a lot of time learning about Drush makefiles, I am curious about what you mean by when you said they are being used less. Do you mean there is better tool/workflow out there that Drupal developers are leaning towards?
Not only for initial set-up/installation
Based on the conversations I've had, folks aren't interested in waiting for the site to rebuild every time they make a change in development. It simply takes too long. So you can use makefiles, or you can use Git. Or you try the other approaches I discuss in the above-mentioned presentation. That's if you want to host the site yourself. As many clients are moving over to Drupal-specific hosting providers, this could very well be the nail in the coffin for Drush makefiles used for this purpose. As far as I know, none of them support it. They would still be useful for crafting distributions and being used as templates upon which folks can build sites. They can be used as foundations, so to speak. That's a use case that's most likely still popular.
- Takes time to build sites.
- Takes CPU cycles to build sites.
- Dependent on network. If you're building on Production, and drupal.org goes down, you're in trouble (unless you're using something like Squid for caching).
I didn't know makefiles were
I didn't know makefiles were used this way. Thanks a lot for clarifying! I look forward to finding out more about this topic in your presentation.
Add new comment