A simplified version of the git flow **development model is used. Feature branches are based directly of master and merged directly into master upon completion.

Creating a new branch

Branches must follow the naming convention {chore/bug/feature}/hyphened-branch-name, use the branch name suggested by Klubhuset, if the branch is related to a task. This allows the branch to be automatically linked to the task.

The branch should be deleted once merged with master.

Aim to minimise the size of a single pull request, such that it is reviewable. A single pull request should implement a single feature and optionally small refactors after 'The Boy Scout Principle'.

Large refactors should be carried out in separate branches.

A new feature branch can be based upon a non-reviewed branch if it depends on the changes introduced. Work can then either be cherry-picked from the feature branch to a new branch that is based on the latest master, or merged into the branch it sprung from.

Pull requests

Pull requests must be reviewed by at least one dev prior to merge, urgent bug fixes are exempt from this rule - but it is still highly recommended to have these reviewed.

Code shipped is the responsibility of both the developer writing the code and the reviewer(s). The developer who opened the pull request is per default responsible for merging and shipping the code, unless explicitly arranged otherwise.

Opening a pull request checklist;

• Test the code locally.
• Ensure the code adheres to the code conventions (‣ or ‣)
• Populate with a clear description of what has been done, link ticket where possible.

Pull request review guidelines;

• When opening a pull request; check and review pull requests from other developers.
• The review should only consider code introduced by the pull request, refactoring of surrounding code can be suggested - but these are never required for merge.
• A review resulting in only minor changes should be pre-emptively 'accepted with comments' which allows merging once comments have been addressed without further review.
• Rejected reviews must be clearly marked either with the reason why they were rejected.
• Comments on pull request should be actionable or clearly marked as not needing any action.
• Syntactic code violation is considered non-blocking. Accept with comments.
• All comments must be resolved.