The Wordpress site I am working on has thousands of posts, is updated hourly, and has dozens of plugins and hacks to get it to work in the way it does.

Can someone explain a git workflow that would allow the following?

Essentially, I want to take everything that is currently there — all Wordpress files, posts, plugins, etc. – and work on it locally. This would include, I presume, copying the database and running it locally. (I am aware of the Mark Jaquith solutions, but obviously can't start afresh with his Wordpress skeleton.)

There are specific reasons why I want to work from the same database and post base, which is unfortunate, but necessary.

I then want to make changes and test on a local environment, and then push it to the live server, along with the database that I will have been using in the local environment. I will have a team which can keep the development database up to date with the content that is being created on the live database (as I don't think there is any other way, right?). I presume also that I will have to manually keep the media uploaded to the live site in sync with the media folder on my local setup.

As such, there will be a point where I want to push what I am working on locally to the live server. I presume everything that is in my git repository (that's different) should just overwrite what is on the live server, and I should upload the development/local database contents to my AWS account and then point the live wp-config file to that database.

Am I thinking this through in the right way? How do large sites like the NY Times deal with conflicting databases with content management systems and other issues when pushing to the live server?

Please also note that we are running Wordpress 3.5 and there is no prospect or possibility of us upgrading because of the specifics of the situation.

1 Answer 1


(I realize this question is five years old, and that the OP probably found a solution already.)

I work on a team that manages a large WordPress website. We have tens of thousands of custom posts, with data being entered/edited dozens if not hundreds of times a day.

We actually break things down a little bit, with git repos for the website theme (where most of the custom development happens) and for each custom plugin we write. We don't make any code edits to the WP core, so no version control is needed for it.

We use a Git Feature Branch workflow for both themes and plugins. There are a lot of guides to feature branch workflows, but at a very basic level, we have a master (production) branch and a develop (UAT/staging) branch. All new features/issues are branched off of develop, and once they are done, are merged back into develop. Develop is merged into master whenever we want to release any new features. (Pretty similar to what is shown here: https://nvie.com/posts/a-successful-git-branching-model/.)

We use GitHub for both code review (feature branches are pushed to GitHub, and then a Pull Request is issued into develop, where the review happens before merging in) and as our "source of truth" for each theme/plugin.

For deployment of our themes/plugins, we use WP Pusher on both our staging and production servers. It connects directly with GitHub, and you can deploy any of your branches almost instantaneously. There are other command line solutions out there that work, e.g. Deployer, but for WordPress, I really don't see anything better than WP Pusher at the moment.

We don't work with production data locally, and instead make use of a lot of dummy data for testing. In the event production data is needed locally (e.g. to debug a rare issue), we just export the MySQL database and import it locally. There are quite a few ways of doing this so I won't go into any detail. It would be very risky to push locally edited databases back up to the server. There are just way too many ways for this to go wrong. Our live production database is always the source of truth for us. (Just make sure you have some automated DB backup system in place.)

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.