A development automation example using Git hooks

Proceeding from the previous chapter, an SQL dump can also be generated automatically after each git merge (and git pull).:

• In .git/hooks of your project create a file named post-merge with the following script:
  

  #!/bin/sh
  
  # Create a dedicated directory to store database dumps if the folder does not exist yet.
  mkdir -p `git rev-parse --show-toplevel`/db-backups
  
  # Ask if the database has been updated to the upcoming merge to decide to use the last commit hash before or after the merge.
  read -p $'[post-merge hook]: Use commit hash from the merge itself for the DB dump instead of the last commit from before the merge (previous config export is in the merge)? [y/N]: ' line </dev/tty
  case "$line" in
    y|Y) drush sql-dump --structure-tables-key=common --result-file=`git rev-parse --show-toplevel`/db-backups/$(date +%Y%m%d\T%H%M%S-)`git branch | grep \* | cut -d ' ' -f2 | sed -e 's/[^A-Za-z0-9._-]/_/g'`-`git rev-parse HEAD | cut -c 1-8`.sql
      ;;
    *) drush sql-dump --structure-tables-key=common --result-file=`git rev-parse --show-toplevel`/db-backups/$(date +%Y%m%d\T%H%M%S-)`git branch | grep \* | cut -d ' ' -f2 | sed -e 's/[^A-Za-z0-9._-]/_/g'`-`git rev-parse HEAD^1 | cut -c 1-8`.sql
      ;;
  esac
  

  We use HEAD^1 to get the last commit hash from before the merge (or pull) if our current database does not represent the code base we are about to pull/merge. In that case, the database dump corresponds with that state of the code base and not the changed code that exists after the merge. This is important when we want to do a correct rollback.

• Make it executable:

  chmod +x .git/hooks/post-merge

The .git directory (thus also the containing hooks folder) isn't versioned. There is, however, a way to put Git hooks in another folder to share them with your team and have them under version control.

To extend the above post-merge file even further add to the bottom:

composer install # Get any new dependencies
drush updb -y # Run the update scripts
drush cr # Clear all caches

That leaves you to do manually just drush cex to commit configuration changes on your feature branch and a drush cim after merging the master branch into your feature branch to get configuration changes made by others. We can not automate that as we want to check for merge conflicts on configuration YAML files before importing.

Use the same method with a pre-commit file to run Code Sniffer automatically on each changed file before a commit.

You can skip executing the pre-commit script by using:

git commit --no-verify

To skip the post-merge script you should use a workaround modifying the script itself first. Just copy-paste the code there to the beginning of your script. This might be useful when you run multiple times git pull on several nested repos in your project and want to run the script only once on your project only after pulling the last repo.

The above are just some examples to use on your local machine. You can use them on your remote repo as well, for example, to enforce that only "clean" code can be merged into your master branch. It is out of the scope of this article. Just look at this example of policy enforcement through git hooks.

More info

• Git Hooks | Atlassian Git Tutorial
• How to Enforce Drupal Coding Standards via Git | Lullabot

Next: What's more? >>