Merge Requests

Merge Requests @ Development Guide:

• You should never create a merge request without creating a Issue, unless you are reverting or cherry picking a commit.
• The Description of all Merge Requests should use the Main Template provided.
  • The Related Issue Section, simply add all the issues related to this merge request. If the Merge Request fulfills/achieves what the Issue(s) outlines please use one of the Keywords so the issue is automatically closed when the merge request is merged. GitLab Keywords.
    • If the merge requets does not achieve / fulfills the Issue, please just mention the issue.
• Checks are run again on the code changes again when we review merge-requests.
• If not merged into the "main" branch please look at the reason why. Reviewers are not allowed to close and not merge a merge request without giving a valid reason. If you believe a reviewer has violated this rule please pm/dm @j3zza on GitLab.
• The Main Branch should always be the target branch.
  • Our default branch is always: "main".
  • Tags are also protected branches.

Note

We do not "squash commits" at all.

What Labels to use?

Labels should represent what the merge request is adding/fixing/changing.

• If you are unsure use the same label from the Issue in the Merge Request.

Main Branch Rule:

• The Main Branch is protected and only Maintainers are allowed to merge or push (inc Merge & Push) to it.

Review Guide:

Are you reviewing merge requests? Well here is a quick guide.

Tip

Run uv run ruff check --fix to find and fix any issues.

1. Check for Bugs.
2. Code breaking bugs. (The code returns a code error)
3. Logic Bugs. (Code does not act in the way intended)
4. Database Bugs / Issues.
5. Check for security vunerablities.
6. Check if the code is intented correctly
7. Check to see if the code is following project standards.
8. Check for documentation changes if required.