h1. Git Workflow We are using "git":https://git-scm.com/ as a versioning system using the "Git Branching Workflows":https://git-scm.com/book/en/v2/Git-Branching-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. h2. 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 h2. Workflow !openatlas_git_workflow.png! 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. h2. 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