I am wondering what the best practices are for putting Drupal code under version control. I'll be mostly using core and standard Drupal modules. I'll be developing a custom theme, and one or two custom modules.

As far as I see it, I have 3 options:

  1. Put the entire Drupal folder under version control. Developers can directly check out the folder in the Apache htdocs folder and go from there.
  2. Check in only my custom code (modules + themes). Developers checkout the code in the appropriate folders.
  3. Set up something like Docker.
  • Docker has nothing to do with it. Some people even version their stack, some don't. Look at the Drupal Composer project or Acquia BLT for great examples of tight VCS.
    – Kevin
    Jul 21, 2017 at 17:48

2 Answers 2


There are different ways to approach this, depending on what you need. The easiest approach is the one you described in #1 (Put the entire Drupal folder under version control).

That allows you to easily checkout the full working copy of the codebase with just Git. The downside is that you are storing a lot of code in your Git repo which already exists in other Git repos (ie: Drupal core, contrib modules, etc).

With Drupal 8, the community is generally moving towards using Composer for managing dependencies and building the Drupal codebase. Then, you only need a composer.json file (which points to specific versions of Drupal core and contrib projects), and your custom code in the Git repository. More information: https://www.drupal.org/docs/develop/using-composer/using-composer-with-drupal

Another option is to create an installation profile, and use Drush Make. This method is deprecated in favor of Composer in Drupal 8, but still works nicely for Drupal 7 projects. This is better suited to common code/configuration that you might use to set up lots of similar sites, rather than one highly-customized and specific site.

Regarding Docker - that's sort of a separate decision. You'll still need to choose one of the above options, and then build the codebase accordingly inside the Docker container (or mount it in a volume).


You should build with Composer as it is the recommended approach. Even Drush recommends installing Drush via composer, on a per-project basis. drupal-composer is a good starter which pretty much sets up an ideal Drupal setup. Drupal and all your modules are defined as Composer dependencies.

What you check in depends more on your workflow than anything else.

  • If you deploy to services like Acquia, Pantheon, OpenShift or some other PaaS where your repo is your web root or has limited deploy scripting, then you have no choice but to check in everything. It's pretty straight-forward, but also the least flexible.

  • If you run a build server, then drupal-composer's default setup is ideal for this. You only check in your code (modules, themes, libs). On each commit, have the build server pull in dependencies, process code, package artifacts, and send them off.

    This setup is great if your workflow involves one or more of the following:

    • You're doing CSS/JS pre-processing (i.e. SCSS, ES modules). You commit the manifest (i.e. package.json, bower.json) and the raw files and the server does the building for you.

    • You're dealing with custom environments (i.e. AWS) that need special deployment procedures.

    • Your environments are containers spawned from images from a registry (i.e. Docker Hub). Build server builds the images for you.

Docker has nothing to do with how you commit code. However...

If you're simply building themes/modules and your repo setup is like the project repos found in Drupal.org (where the module/theme is the only thing in the repo), you could use the official Drupal Docker image for development. Simply run a container, mount the project directory as a directory in modules/themes, enable the module/theme, and start writing code. No Drupal core code will exist on the host nor the repo, only your module/theme.

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.