Gotcha of the Day: Deploying a git non-master branch to WP Engine

I have a number of clients who host sites on WP Engine, and I've become a fan of the service. What you give up in flexibility that a vanilla hosting account provides you more than gain back in performance and robust WordPress tools. The fact that I've been able to talk with a knowledgeable rep on live chat with almost no wait time has been a nice bonus.

WP Engine has git based deployment support. While I still prefer subversion over git, this solution does elegantly solve the problem of deploying content to server with a minimum of confusion.

My standard practice is as follows: after a release I fork off a release branch that is used to host urgent bug fixes. The fixes are eventually merged back into master. At the next deployment, I fork off a new release branch, discarding the old one. And repeat. This approach has served me well for years now.

A week ago, I ran into a significant gotcha: I needed to deploy a fix that had been made on the release branch. However, WP Engine assumes that all deployments are associated with master. In other words, I could make changes to my branch release-2, and I could push that branch to WP Engine, but it wasn't going to actually deploy those files.

After much Googling I arrived at the following recipe:

  git push -n  production release-2:master

That is, push release-2 to master on the remote named production.

This worked. Every once in a while, git surprises me with actually simplifying matters, and it did so in this case. It's still too early to tell how this work-around is going to play for the next release. But at least I got my bug fix deployed in an orderly way. The alternative was to drop back to using sftp and that's no fun at all.