Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
A
arsnova-lite
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 24
    • Issues 24
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 2
    • Merge Requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ARSnova
  • arsnova-lite
  • Wiki
  • Conventions

Last edited by Tom Käsler Mar 07, 2019
Page history

Conventions

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

Clone repository
  • Conventions
  • Daily Log
  • Friday, march 9th
  • Monday, march 12th
  • Project setup
  • Translation
  • Wednesday, march 7th
  • domain model
  • friday, march 16th
  • Home
  • monday, march 5th
  • thursday, march 15th
  • thursday, march 8th
  • tuesday, march 13th
  • tuesday, march 6th
View All Pages