I am asking this question because I searched on internet but cannot find right solution. Actually I want a solution in which multiple developers can work on single wordpress project without creating any mess into each other works, but as we know that in wordpress every thing is maintained in database like which plugin is active and which is not.

If developers install plugins to their local project than how they communicate with each other that every one should install that particular plugin or plugins etc, and some miscommunication can break the site of others if every every developer push/pull the code.

Should we share the database too, to share the plugin/themes settings so that there should no conflicts or little conflicts between the developers.


  • 5
    wp-cli.org will help quite a bit with your workflow.
    – jgraup
    Commented Aug 23, 2016 at 12:47
  • 1
    If possible switch to jekyll or similar. Commented Aug 23, 2016 at 13:38
  • Jekyll is baked into github, which obviously works well with git...
    – DaveRGP
    Commented Aug 23, 2016 at 14:12
  • FWIW, collisions and conflicts aren't completely removed when using something like Git, it just lets you keep said conflicts out of your way until you're ready to "merge" them.
    – user32405
    Commented Aug 23, 2016 at 16:41
  • 1
    Can all developers share a common DB hosted publicly and commit to GIT for version control?
    – MonkeyZeus
    Commented Aug 23, 2016 at 19:20

5 Answers 5


Git for plugins:

Then, use Git to manage composer.json and the changes in the TGM plugin.

The hardest part is to sync database:

Definitely, we should share database. Reconfigure a plugin settings/options is not a good idea.

There're many plugins, both free and premium, which can help.

If you want to try something manually, incorporate wp-cli with the answer of @Wyck.


My team faced a similar problem. We use git to version our own custom code such as plugins and the theme that we write. We use Composer to manage dependencies such as plugins we did not write. We check the composer.json and composer.lock files into git to keep everyone in sync. Each developer is expected to pull the git master branch and run composer update on their playpens frequently so everyone remains up to date.

In the database, the developers mainly care about configuration, and we often use WP-CLI to keep configuration in sync. For example, we have a shell script that runs a WP-CLI command to enable or disable plugins on a per-host basis; some plugins are only used on our content staging host, for example, so the script can be run on any host and will only enable the appropriate set on that host. Some configuration that is too time consuming to script is just documented and reproduced manually if necessary.

We also have a perl script that will completely clone the database from our content staging server on to a QA or dev host. The devs can use this periodically if they want all the current content, though that's usually less important than having the code and configuration. The script performs these tasks:

  • mySQL dump of the content staging server's database, change table names, load into the target server's database
  • use wp-cli to change references to the staging server within the database to refer to the target server
  • sync the uploads directory on the target server with the content staging server's uploads

There are some promising solutions for actually versioning the database that are coming along quickly. VersionPress and Mergebot are the two I know of and there may be others.

I wrote up more technical details of how we set up WordPress to work with git and Composer on my blog. It was necessary to run with WordPress core in its own directory to make a clean separation between the code we want to maintain in git and WordPress core. We treat WordPress itself as a dependency and manage it with Composer.


The best solution I’ve seen to this is to use Bedrock (https://roots.io/bedrock/).

The other answers to this question (Composer, and something to manage your plugins) are good answers; but Bedrock provides a systemised, supported, documented, continually-improved way of doing this, which is preferable to rolling your own.

Also, remember you can have more than one git repo – one for your theme, one for each custom plugin you develop, and then one ‘master’ one for the Bedrock/Wordpress installation itself.

  • "Bedrock provides a systemised, supported, documented, continually-improved way of doing this, which is preferable to rolling your own.". Can confirm, Bedrock is great! Use it with Sage (developed by the same people, Roots) and custom development across a team is decently manageable. There's still hiccups, and @Dan9 answer is more complete, but I can't sing Bedrock's praises enough!
    – samrap
    Commented Aug 23, 2016 at 22:54
  • As an MVC developer, I agree, but the type of work I do WordPress sites on is heavily front end based so the asset management setup in Sage is worth the bad practice of the occasional global.
    – samrap
    Commented Aug 24, 2016 at 0:34

If it's absolutely necessary that you have all the same plugins installed working on the theme or a custom plugin, then I would share the database as well.

We use git and composer to keep the different development environments up to date. Just pull the latest changes and re-run composer and you're set to go.


For that first of all we need to understand the WordPress directory structure. WordPress directory structure is not that user friendly for using git with it. So I would suggest you to use this with rather git friendly modified architecture. No, no need to panic. You don't necessarily have to create this. There are a lot of that kinds of boilerplate or structured WordPress system out there. Just pick one of them and start coding.

Now come to the point of writing well organized code or maitainable code. We actually put our code on wp-content\themes\your-theme. So in most of the git friendly WordPress boilerplate the wp-content part is seperated. And they mostly pull the WordPress repo throuh composer. It make the full project a lot cleaner.

Plugins syncing is another important part. It would be better if you install your plugin through composer. It make the project code a lot cleaner. Here you'll get an overview how to install WordPress plugins through composer.

Now come to the most crucial part, how to sync database. I think it could be more easily done in below 2 ways -

  • All the developer should use one remote database. And frequently create a backup of it.
  • Automate the import export facility of WordPress. It seems complicated, but it's not. Just do some google, hope you can do that.

Hope that helps you.

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.