I wonder if somebody found a solution for the following issue related to Drupal 8 development with Git branches:

  • You work on a new feature in a local feature branch
  • for that you activate a contributed module or you write a custom module. This maybe delivers an own entity type and therefore creates a table after installing
  • Meanwhile you need to fix a bug -> you change to a newly created bugfix branch which starts from the current dev branch
  • After checking out the bugfix branch you import the current configurations to have the current active configuration of the branch -> the module you installed in feature branch is not activated anymore, the files of this module do not exist in the current bugfix branch
  • You do your bugfixing and merge ths bugfix branch into develop branch.
  • you change to your feature branch. To bring your local Drupal project to the status of this branch again you will import the configurations again

And here it comes to an exception: the table already exists in your database. When doing a drush cim it stops every following processing and you need to restart drush cim to import any further configurations.

Who does work with different feature branches and found a solution during development process to deal with this kind of situation?

2 Answers 2


I always have a somewhat up-to-date DB dump from live/master available. When switching between feature branches I can drush sql-drop the DB, drush sql-cli < live.sql and drush cim the branch config. If needed. When switching back into the develop or master branch I do the same steps again.

This means you routinely have to commit your feature's configs into its branch. Or to write really cool install.yml in a custom module and enable that after you switched back into the feature branch.

I guess we will have something automating this in half a year. But for now, it's perfectly fine. At least for me.

  • But this makes it necessary a) to create a SQL dump of the full database of the current branch before switching to another branch and b) to commit this dump into your git repo which can make repos very big. Do you do that as well? Jan 27, 2017 at 13:35
  • No no, I don't commit them. Everybody can always get a fresh live dump in seconds.
    – leymannx
    Jan 27, 2017 at 13:37
  • Ok... but using a live dump simply deletes all table data from your module in the feature branch?! So after checking out the bugfix branch you import the live database dump, do your work, checkout the feature branch again and re-install the module? Jan 27, 2017 at 14:11
  • 1
    I get the data back the moment I drush cim. Because I routinely commit the feature's configs into feature branches. Of course drush dre module_name could be an alternative as well if you have really cool install yamls written. If you come from master or another heavy feature branch into a different feature branch, you would have to activate the module nevertheless if it's not already activated on live and if it's not activated in the branch's extensions.yml
    – leymannx
    Jan 27, 2017 at 14:15

Working with a very large database, it is not always practical to run drush sql-cli < live.sql

Ideally, composer install would be run with an option to disable module uninstalls, followed by drush cim and drush updb and finally a normal composer install, but that is currently not possible.

My solution for now is to capture the composer install removals in a script that runs after the command to re-require the removed packages. Later git checkout restores the state of composer.*, then composer install runs again. So the sequence is:

  1. Update my local repository
  2. Run composer install and filter the output to remove ANSI codes and pull out lines starting with " - Removing" followed by lines starting with "Deleting" and reformat them as composer require commands in a script called composer.reinstall.sh:
composer install | tee >(perl -pe 's/\e\[[0-9;]*m//g'|grep -B1 "^Deleting"|grep "^  - Removing"| perl -pe 's/^  - Removing ([^ ]+) \(([^\)]+)\)/composer require \1:\2/g' > composer.reinstall.sh)
  1. Run the generated script: sh composer.reinstall.sh
  2. Run Drupal scripts (drush cim and drush updb) which depend on package existence
  3. Reinitialize composer files: rm composer.reinstall.sh; git checkout composer.*
  4. Run composer install to uninstall any packages removed from composer.json

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.