I know this question has been asked a thousand times, but I'm really trying to work out how to get the best out of Git when working with WordPress.

I've scoured the web and read dozens of articles, all that seem to cover the topic briefly. Here's a few of the most notable one's I've read recently.

- Version Controlling WordPress

- Managing WordPress Theme Deployments with Git

- Manage your custom WordPress theme using git instead of FTP

Currently, my workflow looks like this.

  • Install WordPress locally
  • Develop Theme
  • Export WordPress Databases from local server
  • Import WordPress Database to remote server
  • Upload WordPress files and theme via FTP
  • Client makes changes
  • Download WordPress files and theme via FTP and export WordPress Databases from remote server
  • Replace files locally
  • Make development changes
  • Re-upload via FTP, export and import database to remote server

I realise Git can streamline this process. It seems the best way to do this is to have a .gitignore file that ignores certain directories that don't need to be tracked, as well as having both a local and remote wp-config.php file.

But how do you handle the databases? Clients will usually make changes (posts/pages/plugins). Do I still need to export from the remote database and import back on my local server?

Can someone suggest the best workflow for me here? And walk me through the steps.

Also, I'd probably like to use Bitbucket as private repos with them are free, unlike GitHub.

Any help would be appreciated.

Thanks in advance!

  • How did it go? Did you figure it out? Having the same issues here.
    – qwerty
    Apr 25, 2013 at 8:45
  • 3
    Could you focus your question a bit? You ask about git, but then jump to databases and git is not a tool for dealing with those essentially.
    – Rarst
    May 12, 2013 at 14:34
  • 4
    I think you question is valid. I have the same workflow and by talking to other developers noticed that they also have the same workflow. But it's really time consuming, and opens a lot of room for error. I would also be interested in a better solution.
    – gdaniel
    May 14, 2013 at 16:25

6 Answers 6


I'm one of the developers of WP Migrate DB Pro, and would like to answer @Ennui's question:

"Do you know if the db url replace script it runs takes into account serialized strings?"

Yes, it does handle serialized data. In fact, that is the primary reason I developed the free version of the plugin back in 2009. :)

Unfortunately I only have a reputation of 41, so couldn't reply to @Ennui's comment. Sorry for that.

  • 1
    Got 50 now :) Great plugin man. May 17, 2013 at 14:57

I am borderline on voting to close this as "not constructive" as it seems to be the kind of thing that will solicit debate and opinion rather than answers. But...

That is not what my work flow looks like, and it makes my approach (and answer) different from most of the rest of the answers so far.

  1. Install WordPress locally
    1. This is cloned from a local bare Git repo containing the latest stable release.
    2. I also keep a local copy of the latest release of a few plugins that I nearly always install.
  2. Build the theme and any plugins necessary
  3. Upload to a public staging server
    1. The client is given access but can't change the code and it told that database edits will not be transferred to the production site.
    2. This means that there is no reason to download the code back to the development server.
    3. And no reason to resync the local database
  4. Make changes to the local site based on our staff and the client's feedback.
  5. Upload changes
  6. Repeat as necessary (but with increasing resistance :) )
  7. If we are providing content, which is not always the case, we (not the client) will clean the database on the staging server and upload content.
  8. Deploy by uploading the local code to the production site.
  9. If we have created content, the content is exported from the staging site via the vanilla export tool and imported into the production site.
    1. This is the only time I have to move the database, and it is done with pretty standard tools. I will use Velvet Blues Update URLs to clean up the database if needed.
  10. Debug
  11. The end

Basically, I keep the client away from my stuff as much as possible until we hand over the site.

Code moves one way-- from local to either staging or production. It never moves the other way. That eliminates some of your steps and give me some peace of mind. I do not want to be blamed for the client's tinkering in my code and I don't want to import some hacked file, which is a non-zero possibility.

And the database only moves once, if at all, which greatly reduces the problem. So I guess I manage the "database moving" problem by reducing or removing the need to move the database. It also reduces database corruption issues that can arise and reduces the chances of importing a hack.

True, I do have to configure the production site-- permalinks, menus, etc.-- but that forces me to work on the production site so I consider it a kind of debugging. It helps me confirm that things work on the production site the way they should.

  • 2
    11. The end - you've never had to maintain/patch/improve a WordPress site?
    – Simon East
    May 12, 2017 at 3:09


I haven't tried this myself (yet), but it claims to deploy everything -- DB included.

There is also a tutorial to go with it: Tutorial part 1 | part 2


Take a look at the bedrock stack. It uses composer to manage the version of Wordpress and third party plugins, and also includes capistrano for deploys, and vagrant / ansible for setting up servers including local virtual servers for development.


I recently did a lot of testing regarding this and here is the workflow I use, which does pretty much what you're asking for:

  • I use wp-cli to manage the wordpress core and update wordpress.
  • I use composer along with http://wpackagist.org to manage plugin and theme dependencies.
  • I use git and put core wp files in the .gitignore. So mostly wp-config.php and child theme files are in git.

I'm not familiar with the db migration tools but would be a great addition to this workflow.

Here are the full details on the workflow http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

  • Isn't it a security risk to have wp-config.php tracked in Git? Sep 1, 2021 at 21:57
  • I think its okay to store wp-config.php in git but extract sensitive info inot an .env file using github.com/vlucas/phpdotenv Sep 15, 2021 at 21:10

Regarding the database "cloning", I use WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

It's a paid service, but doesn't cost much, and easily allows you to pull or push your database from your dev to your live server and vice versa. It changes the URLs and everything else that needs changing on the way.

  • 1
    Do you know if the db url replace script it runs takes into account serialized strings? A simple update query to replace the url is bad because it breaks any serialized string with a URL in it (unless the new URL is the same number of characters as the old URL which is rare to say the least). This breaks text widgets and many plugins among other things. I use this script right now but I'd be interested in this plugin if it does the same thing.
    – Ennui
    May 17, 2013 at 13:21
  • I've just emailed the developer to come along and answer that question. I haven't had the need for that (yet).
    – deadlyhifi
    May 17, 2013 at 14:04
  • 1
    I use this plugin for all my migration needs and have yet to see any issues with serialized strings and the url replace. All custom fields transfer over no problem. Keep in mind it replaces EVERYTHING by default. This includes users/passwords/etc... May 17, 2013 at 14:18

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.