Hi Gareth,

Sounds to me like you have some excellent Git processes and practices. I do much of the same except that I usually use just the Git command line. When I first started with Git many years ago, I tried a few Git GUIs. However, I always ended up frustrated with their limitations. So I focused on using Git command line and haven’t looked back since. The only GUI-like tool that I use for Git is lazygit (available for Windows, MacOS and Linux). Despite the fact that it is a text-based tool, it still works with a mouse. I use this to split up changes into multiple commits when I’ve made unrelated fixes along the way but it is capable of so much more. If you are curious. take a look at this open source project at https://github.com/jesseduffield/lazygit.

Best regards,

Michael

Thanks for your reply. As a plugin and occasional core developer, I do use Git on the command line for cherry picking and hard resets. For ease of use though, I do use a GUI. Generally each bit of functionality has its own commit. If a bit of work is going to take time and needs to be interleaved with other work, then I’ll branch off, do several commits, then when finished make a ‘merge’ branch, squash the commits and then merge that branch into master. That then gives a single commit that can then be cherry picked to previous versions of Moodle branches. I’ll rebase if needed. Matching versions is easy as I (like core releases) tag them. The tags are used when uploading to the Moodle dot org plugins DB too, thus a match between that and the repository.

Kind regards,

Gareth

Hi Gareth,

Thank you for your questions.

Risk of Mistakes: Certainly, there are risks involved. However, if you maintain discipline in committing your changes to an online Git repository, the risks are significantly lower compared to relying on memory and a manual process for updating the Moodle LMS. Just remember to use the –rebase option, otherwise, your Git log could become messy, making it difficult to differentiate between core code and custom commits.

Use a Test Installation: Absolutely. I recommend utilizing a test installation whenever you make code changes to your Moodle LMS site. Nevertheless, I’ve encountered clients without a test setup and a limited maintenance budget. In such cases, I structured things so that their webmaster simply needed to back up the site, access a terminal, and execute the ‘git pull –rebase’ command a few times annually. If any issues arose during this process, they were instructed to note the error and use ‘git rebase –abort’ to revert changes. If they encountered no errors but the site didn’t function post-update, they were advised to restore the backup. So far, there haven’t been any complaints.

3rd Party Plugins: Managing them using Git is feasible, although each plugin requires individual management since they are separate from Moodle. Note that installing a plugin via Git will prevent Moodle from allowing updates within the platform if it detects the .git directory. Additionally, it might be slightly challenging to identify the matching commit for the installed version. Unless a plugin has been customized, it’s simpler to clone the entire repository, ensuring you checkout the relevant branch for your Moodle version, and then replace existing files. For customized plugins, Git can be handy to update the plugin and reapply customizations over the updated version. Occasionally, I create a bash script to automate Moodle and plugin updates. This script can even roll back changes in case of issues or execute the Moodle database update script, streamlining the process. Just remember to update the script when adding or removing 3rd party plugins.

Submodules: Implementing this with plugins as submodules is indeed possible. The success largely depends on the implementation. When handled correctly, the Moodle Git repository doesn’t distinguish between submodules and non-submodule custom commits. Since custom commits are always integrated atop the base Moodle, it functions similarly to any other custom commit not part of the core.

Tip: I’ve found that maintaining a sustainable, long-term code management solution using Git involves making individual commits for each fix, new feature, or addition/removal of a 3rd party plugin, rather than combining multiple changes into one. Merge (squash) commits related to one issue into a single commit. This approach keeps your Git log clean and understandable. When it comes time to implementing Moodle upgrades down the road, you will be able to simply cherry-pick your custom commits into the new Moodle branch, hopefully with minimal merge conflicts. Using ‘git log’ allows you to view your custom commits at the top of the list, above Moodle core commits.

Git is an invaluable tool for source code management. As you customize your site’s over time, its maintenance process will naturally become more intricate. However, once you grasp Git’s capabilities and learn to harness them, it can significantly reduce your workload.

Git’s learning curve might seem steep, but dedicating time to grasp its fundamental functions pays off in the long run. For example, as a developer, I maintain multiple releases of Moodle locally for compatibility testing. Using ‘git pull –rebase,’ updates each instance of Moodle in a mere minute or two, sometimes even less (depending on your computer and Internet speeds). Git promptly notifies me of the successful application of customizations over the latest Moodle version and of any source code integration issues.

There’s so much more to share about using Git for Moodle site source code management, but I believe this already exceeds the scope of a comment.

Hope you found something helpful in this information.

Best regards,

Michael Milette