|
|
# Repository conventions
|
|
|
|
|
|
## Merging
|
|
|
## Workflow
|
|
|
|
|
|
1. Issue
|
|
|
2. Feature-Branch
|
|
|
3. Coding
|
|
|
4. Commit
|
|
|
5. Merge Request
|
|
|
6. Review
|
|
|
7. Merge
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
## Naming
|
|
|
|
|
|
### Branch names
|
|
|
|
|
|
Branch names are found after the following rules:
|
|
|
|
|
|
issue-id-user-story-name-issue-name
|
|
|
|
|
|
E.g. `21-login-screen-project-setup`
|
|
|
|
|
|
They are automatically generated by pressing `Create branch` under the arrow in `Create Merge Request` on the issue page.
|
|
|
|
|
|
### Merge Requests
|
|
|
|
|
|
Merge Requests should have a meaningful title and description. Describe
|
... | ... | |