dbf40c30d8
Add comprehensive documentation for literate programming approach: - Phase 1 guidelines focusing on why/what without implementation - General literate programming principles for code documentation - Project notes explaining wrapper script concept and strategy Decision: Follow literate programming to make the wrapper maintainable and educational. Comments tell the story, code implements it. This foundation enables better collaboration and knowledge transfer. The notes.md establishes the core concept: a reproducible wrapper around the Void installer that automates error-prone LUKS encryption setup while keeping user control over system configuration choices.
42 lines
1.0 KiB
Markdown
42 lines
1.0 KiB
Markdown
# Git-Commit-Regeln
|
|
|
|
## Muss
|
|
|
|
- Keine KI-/Assistant-Attribution in Commit-Messages (z.B. `Co-authored-by: ChatGPT`).
|
|
- Vor dem Commit: verfügbare Checks passend zur Änderung ausführen (Tests/Lint/Format).
|
|
|
|
## Umfang
|
|
|
|
- 1 logische Änderung pro Commit; klein & atomar.
|
|
- Zugehöriges zusammen committen (Code + Tests + Docs derselben Änderung).
|
|
|
|
## Message (Conventional Commits)
|
|
|
|
```
|
|
<type>(<scope>): <subject im imperativ>
|
|
|
|
<body: was + warum, bei ~72 chars umbrechen>
|
|
|
|
<optional: entscheidungen/alternativen/trade-offs>
|
|
<optional footer: issue refs>
|
|
```
|
|
|
|
- Subject: Imperativ, kein Punkt, ideal `<= 50` Zeichen.
|
|
- Body: **was** und **warum**; Kontext nur wenn relevant.
|
|
|
|
### Types
|
|
|
|
`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`
|
|
|
|
## Vermeiden
|
|
|
|
- Nachrichten wie `fix`, `update`, `refactoring`.
|
|
- Unrelated changes in einem Commit.
|
|
- Lange Subjects; "was" ohne "warum".
|
|
|
|
## Ablauf
|
|
|
|
1. In atomare Commits splitten (z.B. `git add -p`).
|
|
2. Checks laufen lassen.
|
|
3. Commit mit aussagekräftiger Message.
|