I have to work with some other people to develop a web site using Joomla. We will create our personal template and we will install and maybe modify some extensions or plugin. We will work in different cities mainly interacting via web and we will work locally having a central repository where saving our works.

We are thinking about what is the best strategy to keep our workflow under version control. We are thinking of using git but then some questions arise:

  1. Should we track the entire Joomla folder?
  2. What about keeping track of the change in database?

I can answer based on how we work at Virya Group - our CTO Marco Dings has been writing these up in a series of articles: http://magazine.joomla.org/issues/issue-apr-2014/item/1842-practical-development-3-project.

We use Atlassian products - Jira, Stash, Confluence etc.

We set up our working environment as a vhost for each project - we're working on scripting this so it's quicker. So each developer has their own local 'playground', and we set up dev.clientsite.com, staging.clientsite.com and then their live site, clientsite.com.

Within the vhost, we have a directory - vcs - and the web root - www.

We use PHPStorm, and we install Joomla into the www directory, and map this to the corresponding web root on the dev/staging/live using remote hosts.

A repository is set up on the project for the client, into this repository we put anything that changes from the vanilla Joomla, and any extensions which are modified in any way, shape or form, including templates.

These are symbolically linked from the VCS directory back into the www directory - so the files 'live' in the VCS repository, but they appear in the www folder as linked files.

We use LESS with our template base, and follow a BEM structure which we have in a separate repository. This is cloned down for each project, and sym-linked as a new template. Any client-specific customisations are then unique to this project, but we can merge in any future changes to all our projects with ease.

Some people will version control the entire site, it really depends what you want to achieve. We're interested in what changes, and we have sole control over that. We create a customer-custom.css file which the customer can change, but everything else is off limits.

As for database version control, that's something we're looking into. We have played around with some options but haven't found anything that ticks all the boxes as yet.

We use a bunch of scripts to automate all of the above, which we're developing and tweaking as we go.

I hope that helps!


We have been using a similar workflow as described above by RCheesly. I'd highly recommend the Atlassian suite of products for project management. This lets us tie commit messages to JIRA tickets to leave an audit trail in bitbucket. We always create a feature branch i.e feature/joomla-update/JIRA-ticket-no, perform work on that branch and test before merging back to master and deploying.

If a new feature is not ready to go live we can merge it to a separate staging branch and deploy that to preview to the clients, allowing us to create clean branches from master for any features that must go live in the meantime. The key to making this work is to ensure the team never commits directly to the master or staging branches and all work that is not yet ready remains on its own branch within the bitbucket repository.

We do keep the entire installation in version control, we only ignore image folders and node_modules. The reason for this is due to our deployment process, we use a hook on our aws production/staging servers that receives the master branch and deploys all file changes. This lets us perform updates locally, test and then deploy.

Our local environment uses docker and Laradock, which I would highly recommend. Although it is geared towards Laravel, it provides a great environment for any PHP based site and allows you to mimic your production environment so you can update with confidence.

The biggest challenge to get around with this method was the database! Initially, we would perform updates locally, push and then perform the same updates on our servers to ensure extension/core migrations were performed in all environments. This is far from ideal.

We started using a CLI tool to perform these updates CLI Helper, which makes the process a bit more reliable and greatly speeds it up. This is better, but not perfect! I'd love to hear from anyone who has found a better database solution!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.