Development with git branches/ gitflow and new modules

Question

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?

Answer 1

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.

Answer 2

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)

3. Run the generated script: sh composer.reinstall.sh
4. Run Drupal scripts (drush cim and drush updb) which depend on package existence
5. Reinitialize composer files: rm composer.reinstall.sh; git checkout composer.*
6. Run composer install to uninstall any packages removed from composer.json