Git Workflow

We are using git as a versioning system using the Git Branching Workflows.
There is some discussion in the global community that this is hindering continuous integration but we like to have a develop branch to, e.g. catch issues before they go into production.
Because we have a fast workflow and merge there often it works pretty well and is "continuous" enough for our purposes.


  • main - the stable version used in productive environments. It is the latest release version which is tested and, to our knowledge, bug-free.
  • develop - here the latest development branches are joined when they are finished.
  • release_candidate - a special branch made from develop a few days before a release. This branch is frozen: no new features allowed, it's only for testing, fixing and manual updates.
Branches in which are used for work in progress have following prefixes:
  • feature/ - e.g. feature/user_profile_image
  • fix/ - e.g. fix/map_bug


If working on a new feature/fix:

  • Start with a new branch from develop and call it feature/something or fix/something if it isn't a critical problem. In case it is a critical problem start a branch from main in preparation of a fast minor release.
    git checkout develop
    git checkout -b feature/something
  • Implement changes, commit
    git add .
    git commit -m "Implemented feature something" 
  • Merge develop regularly to your branch to keep merge conflicts to a minimum but at least before merging back
    git merge develop 
  • Make sure that all tests pass, ideally have 100% coverage and Mypy checks are passing
  • Document database changes (see below) and add translations if needed
  • Merge your branch to develop
    git checkout develop
    git merge feature/something 

About once a month a new release_candidate branch is made from develop which, after some quality checks, is than released and merged into the main branch.
When working in the release_candidate branch please also merge it to the develop branch afterwards.

Database changes

If there are database changes make sure that

  • there is a comment with the issue number at the SQL update script (e.g. install/upgrade/3.12.0.sql) to easier deal with installations that were already partially updated (e.g. the demo-dev version)
  • the database change is noted at util/
  • the database version is added in config/

Updated by Alexander Watzinger about 1 year ago · 26 revisions

Also available in: PDF HTML TXT