---
# System prepended metadata

title: GIT Guidelines

---

# GIT Guidelines

## Branching
We follow the following branching strategies:

- We use a `develop` branch, which is a direct subbranch of the `master` branch. We only merge into the `master` branch for a release 
- Every feature must be on its own branch, directly branching from the `develop` branch. 
- If a feature is splitted further, each part should be on a subbranch, directly branching from the feature branch.
- Naming of feature branches:
    - for a feature branch: `feature/feature-name`
    - for a subfeature branch `feature/feature-name-indicator` (where indicator stands for the specific subtask, e.g. `frontend`)
    - for a bugfix branch: `bugfix/task`, where `task` normally stands for a feature, but also can be other tasks.
    - for other tasks which are not assignable to a feature, a clear and  unmistakably  name should be used

## Commits
Each commit should only contain parts of only **one** feature. Commits refering to the same features should be branched from the same source. 
### Commit Messages
Refers to the branch iteself. Should contain the solved problem (e.g. features, bugfix, ...) and refer to its issue (ticket). The message should also contain a short description what was done.
## Merge Request
Every branch needs a accepted request to get merged. The merge requests must only be accepted by an independent develop member.
## Definition of "Done"

Before a merge-request is started on gitlab, the feature must be "done". We define "done" through the following points:

1. All code parts of the feature must be completed, to complie to the issue and feature-list.
2. Essential parts of the feature must be tested through unit and/or integration tests (e.g. 80% test coverage should be fullfilled)
3. Documentation of the relevant parts (see coding-guidelines)

If one of the above mentioned points are not fullfilled, a merge-request should be rejected in any case.

