I've been reading up and trying out various workflows with Wordpress/git. There's a number of options available and I've got a few workflows roughly modelled but no matter which one I choose there's always someone or something that'll lose out.

Workflow adopters

  1. Developers (competent, used to git)
  2. Designers (not used to git, but competent)
  3. "CMS users" (less competent)


This part isn't really subject to change unless a workflow is really, really worth it.

  1. Production server pulls from prod/master branch
  2. In house development server pulls latest from develop branch
  3. Unit tests are available that should be run before local push to server
  4. When develop receives a push and there's a new tag, automated tests run on the Dev server. If they pass, merge with production

Option A

  • All files stored in git
  • Database schema & content stored in git
  • use of local-config.php files for easy local deployment
  • disallow access to admin panel for live site on production and development server


  • all work done locally
  • easy to redeploy
  • everything is controlled by git for traceability
  • known working version (no auto updates to mess things up potentially)


  • minor edits to posts/pages have to be done via source control each time
  • non-devs may end up using this system more
  • merging a raw SQL file is problematic

Option B

  • All files stored in git
  • Database schema & content stored in git
  • use of local-config.php files for easy local deployment
  • disallow access to admin panel for live site on production only


  • mostly the same as Option A but changes to posts/content can now be done via Dev server
  • easier for less technical folks to understand
  • changes to Dev site db checked in by the server automatically every so often


  • losing traceability with commits as it'll just be a user "server" that committed a page content change
  • opening up potential to have people working on Dev server and skipping local
  • pain to manage

Option C

  • only templates/custom plugins stored in git
  • db backed up by other method (probably manually)
  • posts, pages, plugin installs, updates can be done live on the prod site (yuck)


  • most user friendly


  • least Dev friendly.
  • not quick and easy to redeploy
  • no idea if update to core breaks a test
  • no idea if an update to a plugin breaks stuff
  • users editing pages on the fly live

Is there any good happy medium or better way of working that I'm totally missing or is it a "suck it and see" job where we have to implement it, find the issues folks are having and fix those.

1 Answer 1


You have three types of data:

  • Source code,
  • Configuration,
  • Content.

The first two belong to a version control. This is what you need to rebuild the web application, i.e. get it to a working state after, for instance, your server crashes. This is also all you need to deploy the application to a different server in a different environment, or to run it on a developer machine. This data is created by developers, graphic artists, system administrators and DBAs—persons with technical skills in IT.

Content, on the other hand, belongs to a database. There might be version control built into the application or the database, or the application may use a more usual version control system such as Git to track the changes to content. The content is created by end users—persons who are not expected to have technical skills in IT.

The storage and the versioning of content should be transparent to the end users. They are not expected to do svn commit, and even less to understand the difference between git commit and git push. In practice, such transparency is difficult to achieve: Google Docs got it right by versioning aggressively the smallest changes; SharePoint got it wrong by burdening the end users with the details: version numbers, exclusive locks, etc.

Another difference is the life cycle of the source code and configuration changes on one hand, and content changes on the other. It is expected for the content to be changed quickly. In order to change a page through CMS, a click on “Save” button was enough—the change was immediately in production. On other other hand, changes to source code and configuration had to pass through change control, code reviews, build, testing and deployment. In the past, up to six months could elapse between the moment where the change was suggested and when it finally appeared in production. With the advent of Agile and DevOps, the life cycle is much shorter, sometimes a few minutes only; still, usually, you don't submit content changes to Q&A or redeploy all the servers after the user fixes a typo (but if the typo is fixed by a developer, the story is very different).

This means that you don't need to have a single workflow for everyone. It's like choosing between asking both your developers and your users to use vi or emacs to write both code and documents, or to use Microsoft Word for both groups: the fact that both groups type some text to do their job is irrelevant; different needs require different tools. So keep the ordinary workflow for developers and designers, and let the CMS (or the database) manage versioning of content.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.