@@ -4,11 +4,20 @@ This document outlines some basic rules and guidelines for development within th
## Development Guidelines
***Test-Driven Development (TDD):** Wherever possible, Test-Driven Development principles should be followed. Write tests before writing the code they are intended to validate.
***Pre-commit Hooks:** Use pre commit hooks
* Ensure that `pre-commit` hooks are installed and active before making any commits. This can be done by running `pre-commit install` in your local repository.
* Do NEVER skip the `pre-commits` via the git argument `-n`
-**Test-Driven Development (TDD):** Wherever possible, Test-Driven Development principles should be followed. Write tests before writing the code they are intended to validate.
-**Pre-commit Hooks:** Ensure that `pre-commit` hooks are installed and active before making any commits. This can be done by running `pre-commit install` in your local repository.
## Issue Management
- **Closing Issues:** When a commit fixes or closes an issue, the commit message must include a supported keyword followed by the issue number (e.g., `fixes #123`, `closes #456`).
- **Placement:** This pattern should always be placed at the very end of the commit body (not the subject line).
## PRs
Do create PRs only on a specific user request. Do not create them on your own initiative.
A PR should always contain a note if an issue is closed with it.
## Repository Comparison
* On request, this repository should be compared against the rules and guidelines specified in the `README.md` of the reference repository: `https://git.horstenkamp.eu/Philipp/template-git`.
- On request, this repository should be compared against the rules and guidelines specified in the `README.md` of the reference repository: `https://git.horstenkamp.eu/Philipp/template-git`. The comparison should only move fitting changes to the current repo.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.