WPCloudDeploy Documentation

Introduction To Git Integration


Important Note:  The GIT module is only available as part of a services or upgraded support package.  We fully expect that there will be lots of questions related to how best to apply this module to your use-case and goals.  Since that kind of in-depth, organization-specific support is not something we can reasonably provide for free in our ALL ACCESS bundle support, the only way to offer this feature is by making it part of a services or upgraded support contract.

This is not your standard GIT integration with only web-hooks.  It is a fully distributed bi-directional integration that takes full advantage of the decentralized and distributed nature of GIT.


GIT is a distributed version control system that allow multiple users to simultaneously make changes to files and commit them to a central repository.  Most conflicts are intelligently handled but commits will be rejected if the git server cannot figure out how to merge changes from multiples sources.

This flexibility is also its greatest drawback and lead to a LOT of confusion among developers.

Still, WPCloudDeploy supports this multi-direction, multi-user editing. Though, for most use-cases it is probably better to use a more linear approach.

A typical individual-developer process might look like this:

As you can see, the flow is one way – all changes originate from the developer’s machine.

In this case, there is no need to create a git repository on the server where the site resides.  All that is needed is the git credentials for the central (remote) repository.

However, there are other, more advanced workflows that can be used if git is initialized on the production or staging site on the server and linked to the central (remote) repository.

For example:

ummm…you might be thinking that this looks simpler because there are less blocks on here compared to the last image – so why are we saying this is more complex?

The answer is simple – you’re pushing files / changes in both directions and to multiple machines.

For example, if you add or update plugins & themes on the production or staging server, they can be pushed to the central (remote) repository and then further pushed down to the developer’s local environment.

An even more advanced case is this:

Notice that many of the arrows point in BOTH directions.  In these cases, file changes:

  • Flow both ways between a developer’s local environment and the remote repo (eg; on Github).
  • Flow both ways between multiple developers and the remote repo.
  • Flow both ways between developers and the production (or staging) website.
  • The production (or staging) website can be updated at any time by the webhook trigger when developers (or any other source) push changes to the remote repo.

About The Database

Git is all about files.  Usually plugins and themes and, maybe, the core WordPress files.

There is no version control or syncing of the data in the database.

Changes to the database as you upgrade your site needs to be handled with a custom plugin that deletes, updates and adds data.

Activating Git Options

Git Control is a premium option offered only as a combined software + services product.  The software (plugin) is not available without the services component.

The software is provided as a regular WordPress plugin – upload and activate it from the WordPress PLUGINS screen.

Once activated you will see a few new options:

  • A new GIT tab in your global SETTINGS area under WPCLOUDDEPLOY → APP: WORDPRESS SETTINGS → GIT
  • A  new GIT tab under each server
  • A new GIT tab under each site (if you activated GIT for a server).

Basic Setup

The easiest way to connect your servers and sites to GIT is to setup global GIT options under WPCLOUDDEPLOY → APP: WORDPRESS SETTINGS → GIT

There you can add a few settings that will be used by all your servers and sites.

  • Email Address used for your Git Provider account
  • The display name that will be used by Git
  • The user name for your Git Provider account
  • The API token created in your Git Provider account
  • A primary branch – usually ‘master’ or ‘main’

Some advanced options used for two-way syncing include:

  • pre-processing and post-processing scripts
  • gitignore settings


Supported Git Providers

We only support one provider at this time:

  • Github

Credential Hierarchy

If you’re using the same set of credentials (and other related settings) for all your sites, you only have to set them up in the GLOBAL settings area.  Sites will automatically pull them from there when first initialized with git.

You can also set up server-specific GIT credentials in the server screen.  Sites on the server will pull from those settings first before looking to the global settings for values.

Finally, you can give each site its own unique set of credentials.  This is useful if you’re managing multiple git repos for various customers for sites on a shared server (eg: a development server.)

Support Policy

As mentioned above, this module is only available with a services or upgraded support contact.  But, in the event that we release this module to everyone without the requirement for a services or enhanced support contract, the following terms will apply (text is struck-out because it is not applicable right now given that the module is only available as part of a separate enhanced support or services contract):

Even though GIT Integration is included as part of our ALL ACCESS package, it is not provided with free support.  The reason is simple – git is complex and if you don’t have experience with it, we don’t want to be the ones spending support time handling basic training.

We will respond to SOME support questions for free, especially clearly out-lined bug reports.

All other questions will need to be part of a paid enhanced support contract.

Questions about conflicts, the differences between fetch, pull, checkout etc. are definitely NOT included as part of free support.

This decision is simply one of support resources.  We can easily spend hours helping you learn about git or resolve a series of git conflicts.  That’s just not a good use of our free support resources and just a few of those types of issues will quickly starve other customers of critical support.

The alternative would be to simply not release it at all as a product and, instead, split it into two parts:

  • Simple (webhook support only with a linear workflow) which would be part of the core
  • Everything else we would make part of a services-only offering

If it turns out that folks are really Really not happy with the support policy, we will withdraw it as a stand-alone product and implement the split.