Repository conventions

Keep it clean!

Workflow

1. Issue
2. Feature-Branch
3. Coding
4. Commit
5. Merge Request
6. Review
7. Merge

Important: One branch, one purpose.

Merging

A merge request should only be performed by the scrum master. To reduce workload of the scrum master, please use the tags to sign the merge requests.

• Use ready for testing to mark your merge request as done. Another team member should then checkout this branch and test all changes. Please provide a meaningful description to help them review your work. Test for all possibilities and eventualities, as far as possible. Test beyond the expected behaviour.
• When you are ready with testing, mark the merge request as ready for review. This tag tells the scrum master that the merge request should (in best case) be bug free. The scrum master will then make a code review where he checks whether or not the naming conventions are observed etc.

Merge Requests

Merge Requests should have a meaningful title and description. Describe

• what the issue was (briefly) or what the bug was (briefly)
• how to reconstruate the situation, the issue is linked to
• what the previous behaviour was
• what the expected behaviour is

The description should match the standards in commit messages all over all.

Commit messages

Commit messages should be written in presence and with a capital character at the beginning of the line. They should also be meaningful and on-point. E.g. Update readme