In a previous blog post I discussed how best to manage file and folder permissions when deploying with Git, but today I’ll show a specific example of what that post-receive hook might look like for a WordPress project that uses submodules.

I have three servers that I can deploy to, but the post-receive hook only deploys a project when it encounters the specified branch as defined per server:

1. QA waits for a release branch
2. Staging waits for the master branch
3. Production waits for the master branch

Other than this small difference, the post-receive hook is identical on all three servers to reduce maintenance.

Lastly, each server has two repositories per project:

1. Bare repository – storage unit that uses a post-receive hook to deploy the project.
2. Working repository – web root that will serve the project to the end-user.

This method has several benefits:

1. View a combined list of all version-controlled projects via the /opt/repositories directory.
2. Recover a corrupted web root by cloning a fresh copy from the origin.
3. Prevent some issues that may occur during the deployment, since it will fail before post-receive hook is fired.

Continue reading →