Git-Regeln für KI-Assistenten

Git-Regeln

• Führe niemals git commit oder git push aus — da die Commits mit GPG signiert werden.
• Deine Aufgabe ist es, Änderungen vorzubereiten und nur zu stagen (git add). Der Benutzer wird manuell in seinem eigenen Terminal committen und pushen, wo GPG + TTY funktionieren.
• git stash, git diff, git status, git log, git add und schreibgeschützte Git-Befehle sind alle in Ordnung.
• Für Rückgängig machen / Zurücksetzen verwende git blame, um Änderungen zu identifizieren und Fehler zu vermeiden.
• Rufe das aktuelle Repository zuerst ab, bevor du Änderungen vornimmst. Falls es eine laufende Änderung von Upstream gibt, frage, ob ein Merge/Rebase erforderlich ist.

Mergen / Rebasing auf den Ziel-Branch

Führe diese Schritte in der angegebenen Reihenfolge aus, bevor Du Upstream-Änderungen integrierst:

1. Upstream abrufen

   git fetch origin
   

2. Abweichung prüfen — Commits auf dem Ziel-Branch, die noch nicht auf dem aktuellen Branch sind

   git log HEAD..origin/<ziel> --oneline
   

3. Überlappende Dateiänderungen prüfen

   git diff --name-only HEAD...origin/<ziel>
   

4. Auswirkungen auf Specs/Tests prüfen (siehe unten) — führe dies VOR dem Mergen oder Rebasing durch.

5. Konfliktrisiko bewerten — wenn die Abweichung oder Dateiüberlappung signifikant ist, frage den Benutzer, ob gemergt oder rebased werden soll.

6. Nur stagen — der Benutzer commitet und pusht manuell (GPG-Einschränkung).

Auswirkungsprüfung auf Specs und Tests

Vor jedem Merge oder Rebase, prüfe auf Upstream-Änderungen an Specs/Tests, die sich mit der Arbeit des aktuellen Branches überschneiden:

git diff HEAD...origin/<ziel> -- \
  '*_spec.rb' '*.spec.*' '*.test.*' \
  'spec/' 'test/' '__tests__/' 'tests/'

Wenn sich Spec/Test-Dateien im Upstream geändert haben:

• Zeige den Diff — welche Testdateien haben sich geändert und was hat sich geändert.
• Kennzeichne Überschneidungen im Domain-Bereich — identifiziere, ob die geänderten Tests dieselben Funktionen oder Dateien abdecken, die der aktuelle Branch ändert.
• Vor dem Fortfahren fragen — wenn die Implementierung des aktuellen Branches möglicherweise von veralteten oder neu geänderten Specs getestet wird, frage den Benutzer, ob der Branch zuerst aktualisiert werden soll oder fortgefahren werden kann.

Begründung: Das Zusammenführen von Upstream-Teständerungen in einen Branch mit neuer Implementierung erzeugt falsch-negative CI-Ergebnisse — Tests bestehen, weil sie das alte Verhalten testen. Das Erkennen von Spec-Abweichungen vor dem Merge vermeidet verwirrende Downstream-Fehler.

Konflikte auflösen

• Bei Merge-Konflikten bewerte das Problem und frage den Benutzer, ob wir es lösen sollen oder nicht.
• Löse jeden Konflikt dateiweise auf. Löse nicht alles auf einmal.

Tags

• Folge vorhandenen Versionspräfixen (falls verfügbar).
• Folge dem Versionierungsformat von SemVer (z. B. v1.0.0-beta).

Pull-Request-Standards

• PR-Größe ≤ 200 Zeilen (sofern keine sinnvolle Vereinfachung möglich ist).
• Begrenzter Umfang: Nur Änderungen für das Ticket/Story (kein unzusammenhängendes Refactoring).
• Kurze Beschreibung oder Aufzählungspunkte mit den Änderungen.