Git Commit mit Conventional Commits
Überblick
Erstellen Sie standardisierte, semantische Git-Commits unter Verwendung der Conventional Commits-Spezifikation. Analysieren Sie den tatsächlichen Diff, um Typ, Umfang und Nachricht zu bestimmen.
Format von Conventional Commits
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Commit-Typen
| Typ | Zweck |
|---|---|
feat | Neue Funktion |
fix | Fehlerbehebung |
docs | Nur Dokumentation |
style | Formatierung/Style (keine Logik) |
refactor | Code-Refaktor (kein Feature/Fix) |
perf | Leistungsverbesserung |
test | Tests hinzufügen/aktualisieren |
build | Buildsystem/Abhängigkeiten |
ci | CI/Konfigurationsänderungen |
chore | Wartung/Sonstiges |
revert | Commit rückgängig machen |
Breaking Changes
# Ausrufezeichen nach Typ/Umfang
feat!: entferne veralteten Endpunkt
# BREAKING CHANGE-Fußnote
feat: erlaube Konfiguration zur Erweiterung anderer Konfigurationen
BREAKING CHANGE: Das Verhalten des Schlüssels `extends` hat sich geändert
Arbeitsablauf
1. Diff analysieren
# Wenn Dateien gestaged sind, gestageten Diff verwenden
git diff --staged
# Wenn nichts gestaged ist, Arbeitsverzeichnis-Diff verwenden
git diff
# Auch Status prüfen
git status --porcelain
2. Dateien stagen (falls nötig)
Wenn nichts gestaged ist oder Sie Änderungen anders gruppieren möchten:
# Bestimmte Dateien stagen
git add pfad/zu/datei1 pfad/zu/datei2
# Nach Muster stagen
git add *.test.*
git add src/components/*
# Interaktives Stagen
git add -p
Committen Sie niemals Geheimnisse (.env, credentials.json, private keys).
3. Commit-Nachricht generieren
Commit-Nachrichten MÜSSEN strikt und ausschließlich auf Englisch verfasst werden – sowohl der Betreff als auch der Haupttext. Schreiben Sie niemals eine Commit-Nachricht auf Russisch, selbst wenn die Repository-Historie russische Commits enthält.
Analysieren Sie den Diff, um Folgendes zu bestimmen:
- Typ: Welche Art von Änderung ist dies?
- Umfang: Welcher Bereich/das Modul ist betroffen?
- Beschreibung: Einzeilige Zusammenfassung der Änderungen (Präsens, Imperativ, <72 Zeichen)
4. Commit ausführen
# Einzeiler
git commit -m "<type>[scope]: <description>"
# Mehrzeilig mit Haupttext/Fußnote
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
<optional body>
<optional footer>
EOF
)"
Best Practices
- Schreiben Sie Commit-Nachrichten strikt nur auf Englisch (Betreff und Haupttext)
- Eine logische Änderung pro Commit
- Präsens: "add" nicht "added"
- Imperativ: "fix bug" nicht "fixes bug"
- Issues referenzieren:
Closes #123,Refs #456 - Beschreibung unter 72 Zeichen halten
Git-Sicherheitsprotokoll
- NIEMALS die Git-Konfiguration aktualisieren
- NIEMALS destruktive Befehle (--force, hard reset) ohne explizite Aufforderung ausführen
- NIEMALS Hooks überspringen (--no-verify), es sei denn, der Benutzer verlangt es
- NIEMALS Force-Push auf main/master ausführen
- Wenn ein Commit aufgrund von Hooks fehlschlägt, korrigieren und NEUEN Commit erstellen (nicht amend)
- NIEMALS ohne vorherige explizite Aufforderung des Benutzers einen neuen Branch erstellen.
Committen Sie direkt auf den aktuellen Branch (einschließlich
main), es sei denn, der Benutzer hat einen Branch angefordert. Erstellen Sie NICHT automatisch einen Branch "zur Sicherheit" – der Benutzer verwaltet die Branches. Wenn Sie der Meinung sind, dass ein Branch angebracht ist, FRAGEN Sie vor der Erstellung. - NIEMALS in einen neuen Remote-Branch pushen oder einen MR/PR eröffnen, es sei denn, der Benutzer hat darum gebeten.