Git-Workflow befolgen
Kernregel
production ist der einzige langlebige Branch. Niemals direkt darauf arbeiten.
Vor jeder Git-Schreibaktion:
- Führe
git status --short --branchaus. - Bestätige, dass keine unerwarteten Dateien oder Änderungen vorhanden sind.
- Hole den Remote ab.
- Erstelle oder wechsle zu einem kurzlebigen Aufgaben-Branch.
- Beschränke den Branch auf ein Ziel.
Branchnamen
Verwende:
feat/<scope>fix/<scope>hotfix/<scope>test/<scope>docs/<scope>refactor/<scope>chore/<scope>
Verwende Kleinschreibung mit Kebab-Case. Verwende niemals main, dev-production, changes,
update oder ähnlich vage Namen.
Vor dem Commit
- Überprüfe
git diffundgit diff --staged. - Entferne nicht zusammenhängende Dateien.
- Stoppe, wenn Geheimnisse, private Nachweise, interne URLs, rohe KI-Sitzungen, Kundendaten oder Studentendaten auftauchen.
- Führe die für den geänderten Bereich relevanten Prüfungen aus.
- Verwende eine Conventional Commit Nachricht.
- Füge niemals einen KI-Co-Author-Trailer hinzu, es sei denn, es wird ausdrücklich verlangt.
Push und Pull Request
- Niemals direkt auf
productionpushen. - Niemals
productionper Force-Push überschreiben. - Niemals Hooks oder erforderliche Prüfungen umgehen.
- Niemals einfaches
--forceverwenden. - Verwende
--force-with-leaseauf einem Aufgaben-Branch nur nach ausdrücklicher Genehmigung. - Jede Änderung an
productionerfolgt über einen Pull Request. - Folge
.github/pull_request_template.md.
Merge-Grenze
Claude muss vor dem Merge anhalten, es sei denn, Randi genehmigt ausdrücklich das Mergen des spezifischen Pull Requests im aktuellen Gespräch.
Nur Squash-Merge verwenden. Lösche den Aufgaben-Branch nach dem Merge.
Abschlussbericht
Berichte:
- Branch
- Commits
- Durchgeführte Prüfungen und Ergebnisse
- Pull-Request-Status
- Vertraulichkeitsprüfung
- Verbleibende Risiken
- Ob Merge-Genehmigung noch erforderlich ist
Vollständige Richtlinie
Lies und befolge:
docs/governance/git-workflow.mddocs/governance/github-configuration.md