This page describes how to maintain a copy of Moodle on your production server which can easily be upgraded using Git. If you have customisations of Moodle core code, you are advised to follow the instructions in the Git for developers guide.

To get the most of Git it is worth making the effort to understand its basic concepts - see the section below. It can be a bit of a steep learning curve, especially if you are used to CVS or Subversion.

The command (1) initializes the new local repository as a clone of the 'upstream' (i.e. the remote server based) moodle.git repository. The upstream repository is called 'origin' by default. It creates a new directory named moodle, where it downloads all the files. This operation can take a while as it is actually getting the entire history of all Moodle versions

The command (2) lists all available branches.

Use the command (3) to create a new local branch called MOODLE_32_STABLE and set it to track the remote branch MOODLE_32_STABLE from the upstream repository.

The command (4) actually switches to the newly created local branch.

Note that Git has a huge number of options for each command and it's actually possible to do the above process with a single command (left as an exercise!!).

Git from behind a firewall

Git uses a read-only protocol that may be blocked by your firewall (port 9418). If this is a problem, you can use Github's http version https://github.com/moodle/moodle.git. It's a bit slower, so use the Git protocol if you can.

Updating your installation

The Moodle development team performs integration and testing of fixed bugs every Monday and Tuesday. On Wednesday you can install all patches by updating your code. Check the shortlog to see if the official repository has been already updated or not.

To update your code to the latest version (on the MOODLE_31_STABLE branch) all you have to do is:

$ cd /path/to/your/moodle/
$ git pull

If this is a production site you should still consider the Upgrade instructions (e.g. take backups).

Installing a contributed extension from its Git repository

This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.

For example, let us say we want to install the Certificate module from its Git repository into our Moodle 3.2.

The command (1) changes the current directory into the mod folder of your local Moodle clone. The command (2) creates a new subdirectory certificate and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle 3.2. The command (4) deletes the master that was created automatically by git-clone in (2) as we do not want it in this production checkout.

Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issuing the command below before running the command (3), in order to verify what is available among the branches:

This will avoid an error message when you issue the command (3) against a nonexistent branch, e.g.:

§ git checkout -b MOODLE_31_STABLE origin/MOODLE_31_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_31_STABLE' which can not be resolved as commit?

Now it is wise to add the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.

As it was said in the previous section, this is for advanced users only.
Therefore it is necessary, that you have some experience with Git and its commands.
A step-by-step explanation will be provided, but in order to follow these steps it is helpful to understand, what these commands do.

Advanced options and commands can be found at [Git book].
If you have any questions about Git submodules, please visit the site above first.

The file .gitmodules contains the local path and url of all your submodules.
It has to be commited, if you intend to clone the repository later (see the page Moodle development environment with Git submodules).
Before commiting, make sure to check the configuration of the plugin's Git repository, since the automatically generated settings may be not sufficient.
For future updates it is helpful, to track the remote branch, which corresponds to the Moodle version of your repository.

Git created the branch master which tracks origin/master automatically, because the remote repository has checked out master.
Therefore, create a new branch, which tracks the appropriate remote branch.
Of course, this is only possible, if the remote repository offers those branches.

It has to be ensured, that the commit includes only the changes for the new Git submodule (since -a commits all non-staged changes).

Maintaining Git submodules

Maintaining a set of submodules is extremly easy.
Consider a Moodle repository with several submodules installed.
Keep in mind, that the extension mod_mylittleextension is a fake plugin, created for a test scenario in this example.
It is not an official Moodle module. For updating all your submodules at once, type in:

The command git submodule foreach [another command] walks through all submodule repositiories and executes what is specified by [another command].
In this case it is git pull.
Therefore the module mylittleextension was updated and the main repository isn't clean anymore until changes are committed:

$ git commit -a -m "Plugin updates"

Maintaining plugins with Git submodules has also another application than simplyfying the update process.
In a greater scale it can be used to maintain a Moodle project, where multiple developers need to have an exact copy of your moodle without organizing external plugins manually.
You can read more about this topic at the page Moodle development environment with Git submodules.