Wordpress - Wordpress with Git

Git for plugins:

• Use Composer for plugins which are already packaged on packagist or wpackagist. Add them to composer.json.
• Use TGM Plugin Activation for other 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.