OpenAtlas

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

h2. Main 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. At a release the develop branch is merged into the main branch.

The branches in which the work (in progress) is happening have following prefixes:

* *feature_* - e.g. feature_user_profile_images

* *fix_* - e.g. fix_map_bug

h2. Workflow

If working on a new feature/fix:

* Start with a new branch from *develop* and call it _feature_something_ or _fix_something_

<pre>

git checkout develop

git checkout -b feature_something

</pre>

* Implement changes, commit

<pre>

git add .

git commit -m "Implemented feature something"

</pre>

* Merge *develop* regularly to your branch to keep merge conflicts to a minimum but at least before merging back

<pre>

git merge develop 

</pre>

* Make sure that all tests pass, ideally have 100% coverage and Mypy checks are passing too

* Document database changes (see below) and add translations if needed

* Merge your branch to *develop*

<pre>

git checkout develop

git merge feature_something 

</pre>

Around once a month a new version is released where the *develop* branch is merged into the *main* branch.

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. at install/upgrade/3.12.0.sql)

* that the issue is noted at util/changelog.py

That way it's easier to deal with updates in the *develop* branch when dealing with multiple new features which need database updates.