Install & update via Git
What is Git?
Git is currently the most popular version control system for any kind of software project. A version control system is a bit like a time machine for your code that makes it possible to follow all the changes you've made, work together on the same code in a team and revert mistakes during the development process.
The team behind the Git client Tower have free learning resources on Git. If you are starting out and would like to learn more about version control with Git, check them out: https://www.git-tower.com/learn/
About this tutorial
Kirby is developed using a single Git repository, which is hosted on GitHub. Not only can you follow our development process and contribute your own ideas and code changes there, but you can also use the repository as a Git submodule.
This tutorial describes one of several ways you can install and update Kirby. See the overview page for all supported ways.
Starting a new project
The easiest way to install Kirby is the Starterkit. It can be installed with a single line in the terminal. Navigate to the place where you want to install Kirby and clone the Starterkit code with:
You will now have a full Starterkit installation in the your-project
folder. If you point your web server at it, you should already be able to access your site in the web browser.
Setting up Kirby as a Git submodule
If you want to be able to update Kirby automatically using Git, you now need to install Kirby as a Git submodule. Run the following commands to do this:
The latest version of Kirby is now installed as a Git submodule.
You can of course do all of those steps in a graphical Git tool if you prefer. We recommend Tower for macOS and Windows, but there are of course several other tools you can use.
Updating Kirby
If you want to update Kirby to the latest version, all you need to do is to update the submodule like this:
Command [1]
ensures that the submodule is on the main
branch of the Kirby repo. This branch always receives the latest released and stable Kirby version. The command [2]
then fetches all changes from GitHub and updates the code.
Now you only need to commit the changes to your repo:
Automating updates with a simple script
If you don't want to type all this every time you want to update Kirby, you can add the commands to a simple bash script to make updating even easier:
Save this in the root directory of your site as update.sh
. Make it executable with
From now on you can update your installation with a single line:
Using the latest development version
If you want to checkout the development branch to test the latest features, you can do it in the same way:
Then stage and commit your changes like above. This way, you can easily switch between the develop
and the main
branches.
Updating to a specific version
It is also possible to update to a specific version, for example a security patch:
Command [1]
fetches all the latest changes from GitHub, including all Git tags (which are used to point versions to their commits). The command [2]
then looks for the provided version in the tag list and checks out the commit for that version.
Staging and committing works just the same as in the previous examples.
If you check out a tag, Git will warn you that your repo is in a "detached HEAD" state. This is expected and just means that you are not on a branch but a specific commit.
Kirby uses the Semantic Versioning scheme:
{major}.{minor}(.{patch})
Major releases (e.g 4.0 to 5.0) may contain breaking changes and deprecations. In such a case, you might have to update your code and plugins used in your installation. You can find breaking changes of a new release in the changelogs. If you are updating from older versions, multiple changelogs may apply. Always read them carefully to identify potential issues.
Minor and patch releases (e.g. 4.1 to 4.2 or 4.1 to 4.1.1) can generally be applied without changes to your site code.
Note that the major version of Kirby 3 was the second number (e.g. the major version of Kirby 3.9.0 is 9). So e.g. updates from Kirby 3.8 to Kirby 3.9 also came with breaking changes.
In any case, please never update a live website directly on the server. Test updates locally first to see if something breaks.