Please take the time to read through or you will not get it. Then you just wasted a click and bandwidth. The idea behind this git workflow for WP Engine is to have the most flexibility. The code and practice that follows is to track all WP Engine environments separately in git branches on your local machine. To be able to develop on the master branch and be able to do continuous delivery from on stage and prod branches.

Basically in order to do that wee need 3 branches on our local machines. Each developer will have the same branches and will be tracking the same thing.

This way we have our local branches

  • master –tracking- Development remote on WP engine
  • stage –tracking- Staging remote on WP engine
  • prod –tracking- Production remote on WP engine

Now you have all the flexibility that you can have the following workflow

Git Workflow

  • Multiple developers can be working on their own master branch, even spin off new branches from them to work on specific features if they need
    • each of you can have your own local branches to work on specific features, as they will all be created from master
    • each feature branch should be named by ticket number like feature-122 or feature-128
    • and as you are done you just locally merge it in to master
  • Once it is ready to demo to the QA team all you need to do is push master up to Development remote on WP engine for a demo
  • Once QA approves, you can locally merge master into local stage (which tracks WP engine Staging environment) quickly push it up for Client review and approval on stage branch
    • if not all the changes have been approved by QA, not a problem then only merge that specific feature branch into your local stage
    • if only certain commits are good, still not a problem, then cherry pick those commits from local master (which track WP Engine Dev) into stage (which tracks WP Engine Stage) and push on stage
  • Periodically when it’s deploy day you can locally merge your whole stage branch into local prod branch and up she goes to the WP engine Production environment
  • But wait there is more! If a hot fix is needed for prod environment, you can use your local prod branch to quickly commit a change and up she goes to Production WP Engine Environment.
    • you just need to make sure once the hotfix is done to merge your local prod branch into your local dev and stage and do a push on those as well so other developers get the fix as well. So they don’t override it with their next push to prod.

Here is how you set it up

OK, so I am assuming by now you have logged in to WP engine, set up the environments there Production, Staging, and Development and you added your public keys to all environments. Just go to WP engine Dashboard and make sure you have that. OK, beautiful. Now for the sake of making this easy let’s use XYZZ as a project name example

So when you are on the WP engine dashboard under the Production Tab under “git push sub tab you have this

[dev_git_url] = [email protected]:production/xyzz.git

Then under stage you have

[stage_git_url] [email protected]:production/xyzzstg.git

And under the Development tab you have

[prod_git_url] [email protected]:production/xyzzdev.git

OK now we get to work on your local machine. Before we do that just know we don’t track WordPress core in git. It is completely managed by WP engine.

So we will be adding this git ignore file as soon as we clone the repository.

// visit and download this

k so now we can start.

Set up the git workflow and branches

Before you begin I want to let you know the first guy who sets it up has a different process. For the subsequent developers its easy.

Everything in [] you would need to replace with your own project git URL’s, I gave you examples above how it would look if your project would be named xyzz.

// create the dir and get dev as your master local branch
mkdir [webroot]
cd [webroot]
git clone [dev_git_url] .

// cd to same directory with .git directory
// copy default .gitignore file to this directory
git add .gitignore
git commit -m "Add default gitignore"

// create the local branches
git branch stage
git branch prod

// make sure that the local branches track the remotes, environments that they need to
git remote add -t master stage [stage_git_url]
git remote add -t master prod [prod_git_url]

git config push.default upstream

git push
git push stage master
git push prod master

git branch -u stage/master stage
git branch -u prod/master prod

There you have it, now you have.

  • master -tracking – Development
  • stage- tracking – Staging
  • prod – tracking – Production

Now any other developer that comes after you and wants to set it up on their own machines they need to do the following

mkdir [webroot]
cd [webroot]
git clone [dev_git_url] .

git branch stage
git branch prod

git remote add -t master stage [stage_git_url]
git remote add -t master prod [prod_git_url]

git config push.default upstream

git fetch stage
git fetch prod

git branch -u stage/master stage
git branch -u prod/master prod

You are free as free can be and implement the workflow we just described above.

Now add the initial code

Add the WordPress installation since it’s not added by default by WP engine.

To do that all you need to do is

  • go back to WP engine to the environment
  • create a fresh backup of the site
  • download the backup and add it to your webroot folder
  • checkout your local master branch
  • git add, commit and push up to Development
  • merge local master master to stage branch and send it up to Staging
  • merge local master master to prod branch and send it up to Production

If you want to manage your local WordPress installation with WP CLI then check out my post about common WP CLI commands.

There you go you have everything in sync. WordPress core git ignored. So you don’t override WP engine updates and you are at complete liberty to chose you own workflow.

I hope this helps,