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.

Branches¶

• 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

Workflow¶

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/changelog.py
• the database version is added in config/database_versions.py