KI-Richtlinien für Git-Commits

# Git-Commit-Richtlinien für KI-Sprachmodelle ## Kernprinzipien 1. **Conventional Commits befolgen** (https://www.conventionalcommits.org/) 2. **Präzise und genau sein** - Keine blumige Sprache, Superlative oder unnötige Adjektive 3. **Fokus auf WAS sich geändert hat, nicht WIE es funktioniert** - Die Änderung beschreiben, nicht Implementierungsdetails 4. **Eine logische Änderung pro Commit** - Verwandte, aber unabhängige Änderungen in separate Commits aufteilen 5. **Im Imperativ schreiben** - "Funktion hinzufügen" nicht "Funktion hinzugefügt" oder "Fügt Funktion hinzu" 6. **Immer Body-Text einfügen** - Niemals nur Subject-Commits verwenden ## Commit-Meldungsstruktur ``` ( ): ``` ### Typ (erforderlich) - `feat`: Neue Funktion - `fix`: Fehlerbehebung - `refactor`: Codeänderung, die weder einen Fehler behebt noch eine Funktion hinzufügt - `perf`: Leistungsverbesserung - `style`: Code-Stiländerungen (Formatierung, fehlende Semikolons usw.) - `test`: Hinzufügen oder Aktualisieren von Tests - `docs`: Dokumentationsänderungen - `build`: Build-System oder externe Abhängigkeiten (npm, gradle, Xcode, SPM) - `ci`: CI/CD-Pipeline-Änderungen - `chore`: Routineaufgaben (gitignore, Konfigurationsdateien, Wartung) - `revert`: Einen vorherigen Commit zurücknehmen ### Scope (optional, aber empfohlen) Gibt den Änderungsbereich an: `auth`, `ui`, `api`, `db`, `i18n`, `analytics` usw. ### Subject (erforderlich) - **Maximal 50 Zeichen** - **Erster Buchstabe klein** (außer bei Eigennamen) - **Kein Punkt am Ende** - **Imperativ**: "hinzufügen" nicht "hinzugefügt" oder "fügt hinzu" - **Spezifisch sein**: "E-Mail-Validierung hinzufügen" nicht "Validierung hinzufügen" ### Body (erforderlich) - **Immer Body-Text einfügen** - Mindestens 1 Satz - **Erklären, WAS sich geändert hat und WARUM** - Kontext bereitstellen - **Bei 72 Zeichen umbrechen** - **Durch Leerzeile vom Subject trennen** - **Aufzählungspunkte für mehrere Änderungen verwenden** (`-` oder `*` verwenden) - **Issue-Nummern referenzieren**, falls zutreffend - **Bestimmte Klassen/Funktionen/Dateien erwähnen**, wenn relevant ### Footer (optional) - **Breaking Changes**: `BREAKING CHANGE: ` - **Issue-Referenzen**: `Closes #123`, `Fixes #456` - **Co-Autoren**: `Co-Authored-By: Name ` ## Verbotene Wörter & Phrasen **Diese Wörter NIE verwenden** (sie sind vage, subjektiv oder übertrieben): - Umfassend - Robust - Verbessert - Optimiert (außer Sie geben an, welche Metrik sich verbessert hat) - Besser - Fantastisch - Großartig - Erstaunlich - Leistungsstark - Nahtlos - Elegant - Sauber - Modern - Fortschrittlich ## Gute vs. schlechte Beispiele ### SCHLECHT (kein Body) ``` feat(auth): E-Mail/Passwort-Login hinzufügen ``` **Probleme:** - Kein Body-Text - Erklärt nicht, was tatsächlich implementiert wurde ### SCHLECHT (vager Body) ``` feat: Fantastische neue Login-Funktion hinzufügen Dieser Commit fügt ein leistungsstarkes neues Login-System mit robuster Authentifizierung und verbesserten Sicherheitsfunktionen hinzu. Die Implementierung ist sauber und modern. ``` **Probleme:** - Subjektive Adjektive (fantastisch, leistungsstark, robust, verbessert, sauber, modern) - Gibt nicht an, was hinzugefügt wurde - Body beschreibt Qualität, nicht Funktionalität ### GUT ``` feat(auth): E-Mail/Passwort-Login mit Firebase hinzufügen Login-Ablauf mit Firebase Authentication implementieren. Benutzer können sich jetzt mit E-Mail und Passwort anmelden. Enthält clientseitige E-Mail-Validierung und Fehlerbehandlung für Netzwerkfehler und ungültige Anmeldedaten. ``` **Warum es gut ist:** - Bestimmte Technologie erwähnt (Firebase) - Klarer Scope (auth) - Body beschreibt, welche Funktionalität hinzugefügt wurde - Erklärt, welche Fehlerbehandlung abgedeckt ist --- ### SCHLECHT (kein Body) ``` fix(auth): Doppeltippen des Login-Buttons verhindern ``` **Probleme:** - Kein Body-Text, der den Fix erklärt ### GUT ``` fix(auth): Doppeltippen des Login-Buttons verhindern Login-Button nach dem ersten Tippen deaktivieren, um doppelte Authentifizierungsanfragen zu verhindern, wenn der Benutzer schnell mehrfach tippt. Button wird nach Abschluss oder Fehlschlag der Authentifizierung wieder aktiviert. ``` **Warum es gut ist:** - Imperativ - Bestimmtes Problem beschrieben - Body erklärt sowohl das Problem als auch den Lösungsansatz --- ### SCHLECHT ``` refactor(auth): Hilfsfunktionen extrahieren Code besser und wartbarer machen, indem Funktionen extrahiert werden. ``` **Probleme:** - Subjektiv (besser, wartbar) - Nicht spezifisch, welche Funktionen ### GUT ``` refactor(auth): Hilfsfunktionen in statische Struct-Methoden extrahieren Private Funktionen randomNonceString und sha256 in statische Methoden der AppleSignInHelper-Struct konvertieren, für bessere Codeorganisation und Namespacing. ``` **Warum es gut ist:** - Bestimmte Änderung beschrieben - Erwähnt genaue Funktionsnamen - Body erklärt Begründung und neue Struktur --- ### SCHLECHT ``` feat(i18n): Lokalisierung hinzufügen ``` **Probleme:** - Kein Body - Zu vage ### GUT ``` feat(i18n): Englische und türkische Übersetzungen für Login-Bildschirm hinzufügen String Catalog mit Übersetzungen für Login-UI-Elemente, Alerts und Authentifizierungsfehler auf Englisch und Türkisch erstellen. Deckt alle benutzersichtbaren Strings in LoginView, LoginViewController und AuthService ab. ``` **Warum es gut ist:** - Bestimmte Sprachen erwähnt - Klarer Scope (i18n) - Body listet auf, was übersetzt wurde und welche Dateien --- ## Richtlinien für Multi-Datei-Commits ### Wann Commits aufteilen Änderungen in separate Commits aufteilen, wenn: 1. **Verschiedene logische Anliegen** - Commit 1: Funktion hinzufügen - Commit 2: Tests für Funktion hinzufügen 2. **Verschiedene Scopes** - Commit 1: `feat(ui): Button-Komponente hinzufügen` - Commit 2: `feat(api): Endpunkt für Button-Aktion hinzufügen` 3. **Verschiedene Typen** - Commit 1: `feat(auth): Login-Formular hinzufügen` - Commit 2: `refactor(auth): Validierungslogik extrahieren` ### Wann Commits kombinieren Änderungen in einem Commit kombinieren, wenn: 1. **Eng gekoppelte Änderungen** - Funktion und ihre Verwendung in derselben Komponente hinzufügen 2. **Atomare Änderung** - Funktionsnamen über mehrere Dateien hinweg umbenennen 3. **Ohne einander nicht funktionsfähig** - Schnittstelle und ihre Implementierung zusammen hinzufügen ## Datei-Level-Commit-Strategie ### Beispiel: LoginView-Änderungen Wenn LoginView 2 unabhängige Änderungen hat: **Änderung 1:** Stack-View-Struktur refaktorieren **Änderung 2:** Ladeindikator hinzufügen **In 2 Commits aufteilen:** ``` refactor(ui): Content-Stack-View als Property in Login-View extrahieren Inline-Stack-View-Initialisierung durch property-basierten Ansatz ersetzen, für bessere Codeorganisation und Wiederverwendbarkeit. Stack-View-Definition von setupUI-Methode in Lazy-Property verschieben. ``` ``` feat(ui): Ladezustand mit Activity-Indicator zur Login-View hinzufügen Ladeindikator-Overlay und setLoading-Methode hinzufügen, um Benutzerinteraktion während der Authentifizierung zu deaktivieren und Inhalt abzudunkeln. Inhalt-Alpha wird beim Laden auf 0.5 reduziert. ``` ## Spezifische Richtlinien für Lokalisierung ### GUT ``` feat(i18n): Englische und türkische Übersetzungen hinzufügen String Catalog (Localizable.xcstrings) mit englischen und türkischen Übersetzungen für alle Login-Bildschirm-Strings, Fehlermeldungen und Alerts erstellen. ``` ``` build(i18n): Türkische Lokalisierungsunterstützung hinzufügen Türkische Sprache zu Projektlokalisierungen hinzufügen und String-Catalog-Generierung (SWIFT_EMIT_LOC_STRINGS) in Build-Einstellungen für Debug- und Release-Konfigurationen aktivieren. ``` ``` feat(i18n): Login-View-UI-Elemente lokalisieren Hartcodierte Strings durch NSLocalizedString in LoginView für Titel, Untertitel, Labels, Platzhalter und Button-Titel ersetzen. Der gesamte benutzersichtbare Text unterstützt jetzt Lokalisierung. ``` ### SCHLECHT ``` feat: Umfassende Mehrsprachunterstützung hinzufügen Fantastisches Lokalisierungssystem zur App hinzufügen. ``` ``` feat: Übersetzungen hinzufügen ``` ## Breaking Changes Bei der Einführung von Breaking Changes: ``` feat(api): Authentifizierungsantwortstruktur ändern Authentifizierungsendpunkt gibt jetzt Benutzerobjekt im 'data'-Feld zurück, statt auf Root-Ebene. Dies ermöglicht zusätzliche Metadaten in der Antwort. BREAKING CHANGE: Alle API-Konsumenten aktualisieren, um auf response.data.user statt response.user zuzugreifen. Migrationsanleitung: - Vorher: const user = response.user - Nachher: const user = response.data.user ``` ## Commit-Reihenfolge Bei der Vorbereitung mehrerer Commits diese logisch ordnen: 1. **Abhängigkeiten zuerst**: Bibliotheken/Konfigurationen vor Verwendung hinzufügen 2. **Grundlage vor Funktionen**: Modelle vor Views 3. **Build vor Quellcode**: Build-Konfigurationen vor Codeänderungen 4. **Hilfsmittel vor Konsumenten**: Helfer vor Komponenten, die sie verwenden ### Beispiel-Reihenfolge: ``` 1. build(auth): Sign in with Apple-Berechtigung hinzufügen Berechtigungsdatei mit Sign in with Apple-Fähigkeit für die Aktivierung der Apple-ID-Authentifizierung hinzufügen. 2. feat(auth): Kryptografische Helfer für Apple Sign-In hinzufügen Hilfsfunktionen für die Generierung von zufälligem Nonce und SHA256-Hashing hinzufügen, die für den Apple-Sign-In-Authentifizierungsablauf erforderlich sind. 3. feat(auth): Apple Sign-In-Authentifizierung zu AuthService hinzufügen signInWithApple-Methode zum AuthService-Protokoll und zur Implementierung hinzufügen. Verwendet OAuthProvider-Credential mit idToken und Nonce für die Firebase-Authentifizierung. 4. feat(auth): Apple Sign-In-Ablauf zum Login-View-Model hinzufügen loginWithApple-Methode in LoginViewModel implementieren, um die Apple-Authentifizierung mit idToken, Nonce und fullName zu behandeln. 5. feat(auth): Apple Sign-In-Autorisierungsablauf implementieren ASAuthorizationController-Delegate-Methoden hinzufügen, um den Apple-Sign-In-Autorisierungsablauf, die Credential-Validierung und die Fehlerbehandlung zu behandeln. ``` ## Spezialfälle ### Konfigurationsdateien ``` chore: GoogleService-Info.plist aus der Versionskontrolle ausschließen GoogleService-Info.plist zu .gitignore hinzufügen, um das Committen von Firebase-Konfiguration mit API-Schlüsseln zu verhindern. ``` ``` build: iOS-Deployment-Target auf 15.0 aktualisieren Mindest-iOS-Version von 14.0 auf 15.0 ändern, um async/await-Syntax in Authentifizierungsabläufen zu unterstützen. ``` ``` ci: GitHub-Actions-Workflow für Tests hinzufügen Workflow hinzufügen, um Unit-Tests bei Pull Requests auszuführen. Läuft auf macOS latest mit Xcode 15. ``` ### Dokumentation ``` docs: API-Authentifizierungsanleitung hinzufügen Firebase-Authentifizierungs-Setup-Prozess dokumentieren, einschließlich Google-Sign-In- und Apple-Sign-In-Konfigurationsschritten. ``` ``` docs: README mit Installationsschritten aktualisieren SPM-Abhängigkeits-Installationsanweisungen und Firebase-Setup-Anleitung hinzufügen. ``` ### Refactoring ``` refactor(auth): Hilfsfunktionen in statische Struct-Methoden konvertieren Apple-Sign-In-Hilfsfunktionen in AppleSignInHelper-Struct mit statischen Methoden kapseln, für bessere Codeorganisation und Namespacing. Konvertiert randomNonceString und sha256 von privaten Funktionen zu statischen Methoden. ``` ``` refactor(ui): E-Mail-Validierung in separate Methode extrahieren E-Mail-Validierungs-Regex-Logik von loginWithEmail in isValidEmail-Methode verschieben, für Wiederverwendbarkeit und Testbarkeit. ``` ### Leistung **Die Verbesserung angeben:** SCHLECHT: `perf: Login optimieren` GUT: ``` perf(auth): Login-Anfragezeit von 2s auf 500ms reduzieren Anfrage-Caching für Firebase-Konfiguration hinzufügen, um wiederholte Netzwerkaufrufe zu vermeiden. Konfiguration wird nach dem ersten Abruf zwischengespeichert. ``` ## Anforderungen an den Body-Text **Mindestanforderungen für Body-Text:** 1. **Mindestens 1-2 vollständige Sätze** 2. **Beschreiben, WAS sich spezifisch geändert hat** 3. **Erklären, WARUM die Änderung nötig war (wenn nicht offensichtlich)** 4. **Betroffene Komponenten/Dateien erwähnen, wenn relevant** 5. **Technische Details einbeziehen, die aus dem Subject nicht ersichtlich sind** ### Gute Body-Beispiele: ``` Ladeindikator-Overlay und setLoading-Methode hinzufügen, um Benutzerinteraktion während der Authentifizierung zu deaktivieren und Inhalt abzudunkeln. ``` ``` signInWithApple-Methode aktualisieren, um fullName-Parameter zu akzeptieren und appleCredential für die ordnungsgemäße Benutzerprofilerstellung in Firebase zu verwenden. ``` ``` Hartcodierte Strings durch NSLocalizedString in LoginView für Titel, Labels, Platzhalter und Buttons ersetzen. Der gesamte UI-Text unterstützt jetzt englische und türkische Übersetzungen. ``` ### Schlechte Body-Beispiele: - `Funktion hinzufügen.` (zu vage) - `Dateien aktualisiert.` (erklärt nicht, was) - `Fehlerbehebung.` (erklärt nicht, welcher Fehler) - `Refactoring.` (erklärt nicht, was refaktoriert wurde) ## Vorlage für KI-Modelle Wenn ein KI-Modell gebeten wird, Commits zu erstellen: ``` 1. Git-Diff lesen, um ALLE Änderungen zu verstehen 2. Änderungen nach logischem Anliegen gruppieren 3. Commits nach Abhängigkeit ordnen 4. Für jeden Commit: - Passenden Typ und Scope wählen - Spezifisches, präzises Subject schreiben (max. 50 Zeichen) - Detaillierten Body schreiben (mindestens 1-2 Sätze, erforderlich) - Imperativ verwenden - Verbotene Wörter vermeiden - Fokus auf WAS sich geändert hat und WARUM 5. Ausgabeformat: ## Commit [N] **Titel:** ``` type(scope): subject ``` **Beschreibung:** ``` Body-Text, der erklärt, was sich geändert hat und warum. Bestimmte Komponenten, Klassen oder Methoden erwähnen. Kontext bereitstellen. ``` **Hinzuzufügende Dateien:** ```bash git add pfad/zur/datei ``` ``` ## Abschließende Checkliste Vor dem Vorschlagen eines Commits überprüfen: - [ ] Typ ist korrekt (feat/fix/refactor usw.) - [ ] Scope ist spezifisch und aussagekräftig - [ ] Subject ist im Imperativ - [ ] Subject ist <=50 Zeichen - [ ] **Body-Text ist vorhanden (erforderlich)** - [ ] **Body hat mindestens 1-2 vollständige Sätze** - [ ] Body erklärt WAS und WARUM - [ ] Keine verbotenen Wörter verwendet - [ ] Keine subjektiven Adjektive - [ ] Spezifisch darüber, WAS sich geändert hat - [ ] Betroffene Komponenten/Dateien erwähnt - [ ] Eine logische Änderung pro Commit - [ ] Dateien korrekt gruppiert --- ## Beispiel-Commit-Meldung (vollständig) ``` feat(auth): E-Mail-Validierung zum Login-Formular hinzufügen Clientseitige E-Mail-Validierung mit Regex-Muster implementieren, bevor die Authentifizierungsanfrage gesendet wird. Validiert, ob das Format dem Standard-E-Mail-Muster entspricht (benutzer@domain.ext) und zeigt Fehlermeldung für ungültige Eingaben an. Verhindert unnötige Firebase-API-Aufrufe für fehlerhafte E-Mails. ``` **Was dies gut macht:** - Klarer Typ und Scope - Spezifisches Subject - Body erklärt, was die Validierung tut - Body erklärt, warum sie benötigt wird - Erwähnt den Nutzen (verhindert API-Aufrufe) - Keine verbotenen Wörter - Durchgehend Imperativ --- **Denken Sie daran:** Eine gute Commit-Meldung sollte es jemandem ermöglichen, die Änderung zu verstehen, ohne den Diff anzusehen. Seien Sie spezifisch, präzise, objektiv und fügen Sie immer aussagekräftigen Body-Text hinzu.

KI-Richtlinien für Git-Commits

Prompt-InhaltSpeichern

Verwendung

Referenzen

Diskussion