In a recent post I started with an overview of Git. Git is a version control management system which is widely used nowadays. It is easy to setup and makes way for collaboration in teams. In the process of developing a website or application with multiple developers, a good Git workflow is very important. Here we discuss the heart of this collaboration with the Git commands push and pull. Because the major CMS systems around (e.g., WordPress, Drupal, Joomla) work with databases to save your sites configuration it is also important to sync your database between the developers, and more importantly, between the local development environments and the staging and production environments. Here we go!

Git push en git pull

The last thing we discussed in the first part was merging your changes of your develop branch into the release branch. Remember: the develop branch is where you are working in locally, the release branch is meant to be in sync with the code on the staging server. Now let’s say that another team member starts working on the project. Clearly he needs the latest changes in his local environment. So the changes you made to the code should be integrated with his code. This is where the Git commands push and pull come into play. You have to push your changes to a remote repository (Bitbucket and Github offer these things) and give access to the other developer to pull your latest commits. In our projects we tend to use Bitbucket when the code should remain private. For opensource development Github is our place to go. Pushing your code to the remote repository (assumed you have that setup properly) is simple with this command:

git push origin develop

Your code will be uploaded to the remote branch (the origin) and is available for the other developer. He can pull this commit to his local environment using this command:

git pull

Now he can proceed developing the site or app. A normal workflow is to commit your changes to your local repository quite often and push your changes to the online repository when you have a chunk of code completed (and tested!) or it is the end of the day and someone else will proceed on the project the next day. When starting with the project you generally pull the latest changes.

Deployment

So far so good, we have managed to change our code and keep our code in version control. We also have been busy sharing our code with other developers in the team by using a remote repository. But the code is only local, so our client is not able to see the latest changes or development of his site or application. One way to make the site available for the client (but not yet to the rest of the world) is by using a staging environment. Ideally this is a server that mimics the behaviour of the live server. We often just make subdomain of the live site: If the site will run on www.example.com, the staging environment will be on www.stage.example.com. Via the .htaccess file we can easily prevent other people to see the site before it is ready.

So in our workflow we have a branch to for development (and maybe some short-living branches that are created to implement specific features), a release branch and a master branch. We keep the code in the release branch in sync with the code on the staging server. So after we have thoroughly tested the new feature in the development branch, these changes are merged into the release branch. Then it is time to deploy these changes to the staging server. In principal it is best to do this automatically, i.e., at the moment of pushing the release branch to the remote, a script can be activated to upload these changes to the staging server. However, until now we haven’t done so. So we have to do this manually. Connect to the server using your favourite FTP client (FileZilla) and upload the code from the development directory (the release branch should be the active branch) to the FTP.

Your client is now able to see the latest features and if he is happy we assume that you get the green light to push these features to the live environment. This is typically not something you automate because if you push the master branch by accident the changes would be visible on the live environment. This deployment step is therefore performed manually.

Syncing your WordPress database

Up to this point we discussed collaboration in a project with respect to the code. These are the files you work on. However, when working with a CMS, the site’s configuration is often stored in the database. For example in WordPress, if you change the content of a page or you add a new image or you make some other changes in the settings, these are stored in specific tables of the WordPress database. If you have pushed all your changes and your co-developer pulls them into his local project, he only has the changed files! Not the changed database! Apart from the files, you should also migrate the database. Luckily there is a very good plugin for this developed by Delicious Brains: WP Migrate Pro. This plugin makes migrating your WordPress database very easy. To make this plugin work you need to install it on each local environment and in the staging and production environments.

Although this plugin does the job quite nicely, there are situations that give us some headaches. Assume that my teammate and I are working on the same site at the same moment. Changes in the files are no problem because we are using Git for version control and the worst thing that can happen is a few merge conflicts at the end of the day. But if we both change the database (by installing plugins, updating plugins, adding users etc.) how can we merge these changes? I have not found an answer to this issue, only a workaround: only one of us makes changes to the database and when necessary we sync our code and the database via the release branch and the staging environment.

Regarding the above issue we are pleased to hear how you approach a multi developer WordPress project and syncing the database in particular. Please, leave your comments below!