Commit guidelines

We use feature branches

Note:

1. Every feature is developed in a new feature branch
2. The branch gets named "feature/<the feature to be implemented>" (e.g. feature/adding-data-generator)
3. After the development of the feature, the developer(s) make(s) a pull request for merging into main
4. The pull request has to be reviewed by at least one of the other developers
5. After a review, the reviewer(s) approve(s) the pull request and merge(s) the code into main

Fixes are also made in separate branches

Note: Fixes follow the same procedure as features. A separate branch named "fix/<the fix>" has to be created and merged after a review.

We use semantic committing

Note: Every commit gets tagged by one of the tags below: (example: #feat Add data generator; #chore Change config file)

• #feat (new feature)

• #fix (bug fix)

• #docs (changes to documentation)

• #style (formatting, missing semi colons, etc; no production code change)

• #refactor (refactoring production code, e.g. renaming a variable, outsource some code, ...)

• #test (adding missing tests, refactoring tests; no production code change)

• #chore (updating grunt tasks etc; no production code change, e.g. alter .gitignore, add comments, change config file, ...)

Commit message style

Note: Commit messages are written in presence, e.g. #test Add tests, NOT #test Added tests