Was macht Git Workflow Automation?

Vollständige Git-Workflow-Automation für den Feature-Entwicklungszyklus – vom Branch-Erstellen bis zum Merge.

Überblick

Diese Fähigkeit automatisiert den kompletten Feature-Entwicklungsworkflow:

Feature-Branch erstellen vom Default-Branch aus
Änderungen committen mit Emoji-Conventional-Commits
Pushen zum Remote-Repository
PR erstellen mit strukturierter Markdown-Vorlage
Auf Reviews warten – auf Code-Review-Kommentare warten
Auswerten und Beheben – jeden Kommentar kategorisieren und beheben
Fixes pushen und antworten – Änderungen pushen, jeden Kommentar bestätigen
Wiederholen – erneut auf neues Feedback zu Fixes prüfen
Status überwachen (UNSTABLE -> CLEAN)
PR mergen (squash + Branch löschen)
Aufräumen lokale und entfernte Branches löschen

⚠️ VERPFLICHTEND: Bei Ausführung des vollständigen Workflows MÜSSEN ALLE 11 Schritte sequenziell ausgeführt werden. Hören Sie NICHT nach dem Erstellen des PRs auf (Schritt 4). Die Schritte 5-11 (Review, Behebung, Merge, Aufräumen) sind obligatorische Bestandteile des Ablaufs, keine optionalen Folgeschritte. Fahren Sie von jedem Schritt zum nächsten fort, ohne anzuhalten.

Auslösen der Fähigkeit

Verwenden Sie natürliche Sprache, um einen beliebigen Teil des Workflows aufzurufen:

Vollständiger Workflow

"Kompletten Git-Workflow für Feature X ausführen"
"Feature-Branch erstellen, commiten, PR und merge"
"Vollständigen PR-Zyklus ausführen"

Einzelne Schritte

"Einen Feature-Branch für X erstellen"
"Meine Änderungen mit Emoji-Conventional-Commits committen"
"Einen PR mit strukturierter Vorlage erstellen"
"Meinen PR-Status überwachen"
"PR mergen und aufräumen"

Review-Handling

"Nach PR-Kommentaren suchen und diese bearbeiten"
"Review-Kommentare auf PR #123 beheben"
"Feedback zum aktuellen PR bearbeiten"

Schritt 1: Feature-Branch erstellen

# Default-Branch erkennen (main, master, etc.)
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | sed 's/.*: //' || echo "main")
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git checkout -b feat/beschreibender-name

Branch-Namenskonventionen:

feat/ - Neue Features
fix/ - Fehlerbehebungen
docs/ - Dokumentation
refactor/ - Code-Umstrukturierung
perf/ - Leistungsverbesserungen
test/ - Tests hinzugefügt/geändert
chore/ - Wartungsaufgaben
ci/ - CI/CD-Änderungen

Schritt 2: Mit Emoji-Conventional-Commits committen

Stagen und Committen

git add <dateien>
git commit -m "<emoji> <typ>[optionaler scope]: <beschreibung>"

Commit-Typen und Emojis

Typ	Emoji	Beschreibung	Beispiel
`feat`	✨	Neues Feature	`✨ feat(auth): JWT-Token-Validierung hinzufügen`
`fix`	🐛	Fehlerbehebung	`🐛 fix(api): Speicherleck im Handler beheben`
`docs`	📝	Dokumentation	`📝 docs: API-Endpunkt-Dokumentation aktualisieren`
`style`	🎨	Code-Stil	`🎨 style: Code mit Prettier formatieren`
`refactor`	♻️	Code-Umstrukturierung	`♻️ refactor: Authentifizierungslogik vereinfachen`
`perf`	⚡️	Leistung	`⚡️ perf: Datenbankabfrageleistung optimieren`
`test`	✅	Tests	`✅ test: Unit-Tests für den Benutzerservice hinzufügen`
`chore`	🔧	Wartung	`🔧 chore: Build-Abhängigkeiten aktualisieren`
`ci`	👷	CI/CD	`👷 ci: GitHub Actions-Workflow hinzufügen`
`build`	📦	Build-System	`📦 build: Upgrade auf Webpack 5`
`revert`	⏪	Rückgängig machen	`⏪ revert: Zahlungsintegration rückgängig machen`

Commit-Nachrichtenformat

Einfach (Standard):

✨ feat(auth): JWT-Token-Validierung hinzufügen

Vollständig (mit Body):

✨ feat(auth): JWT-Token-Validierung hinzufügen

Middleware zur JWT-Token-Validierung implementieren, die:
- Token-Signatur und -Ablauf validiert
- Benutzeransprüche aus der Payload extrahiert
- Benutzerkontext zum Request-Objekt hinzugefügt

Dies verbessert die Sicherheit, indem sichergestellt wird, dass alle
geschützten Routen Authentifizierungstokens korrekt validieren.

Co-authored-by: Claude <[email protected]>

Best Practices

✅ Präsens, imperativer Modus verwenden ("hinzufügen" nicht "hinzugefügt")
✅ Erste Zeile unter 50 Zeichen halten (max. 72)
✅ Ersten Buchstaben groß schreiben
✅ Kein Punkt am Ende der Betreffzeile
✅ Scope für Kontext verwenden (z. B. feat(auth):)
✅ Co-authored-by:-Fußzeile für KI-unterstützte Commits einfügen

Schritt 3: Zum Remote pushen

git push -u origin feat/beschreibender-name

Schritt 4: PR mit strukturierter Vorlage erstellen

Vor dem Erstellen des PRs die tatsächlichen Änderungen analysieren:

# Alle Änderungen in diesem Branch vs. Default-Branch anzeigen
git diff "$DEFAULT_BRANCH"...HEAD

# Commit-Nachrichten anzeigen
git log "$DEFAULT_BRANCH"..HEAD --pretty=format:"%s"

Sie MÜSSEN den PR-Titel und -Body aus dem tatsächlichen Diff generieren – niemals Platzhaltertext verwenden.

Titel: Emoji und Typ vom primären Commit verwenden (z. B. ✨ feat:, 🐛 fix:). Emoji einschließen.
Body: Jeden Abschnitt mit ECHTEM Inhalt aus dem Diff füllen. Nicht [Einzeilige Zusammenfassung] oder [Erste Änderung] schreiben – schreiben Sie tatsächliche Beschreibungen der echten Änderungen.

gh pr create \
  --title "<EMOJI> <TYP>: <kurze beschreibung>" \
  --body "$(cat <<EOF
## 📝 Zusammenfassung

[Eine ECHTE einzeilige Zusammenfassung basierend auf dem tatsächlichen Diff schreiben]

## 🔄 Änderungen

[Jede sinnvolle Änderung als Aufzählungspunkt mit Emoji-Präfix auflisten. Basierend auf git diff-Ausgabe]

## ✅ Überprüfung

[Spezifische, ausführbare Überprüfungsschritte basierend auf dem, was sich tatsächlich geändert hat, angeben]

## 🔗 Quellen

[Relevante Links einfügen: Issue-Referenzen (Closes #N), Dokumentation, verwandte PRs. Abschnitt weglassen, wenn keine vorhanden]

---

🤖 Generiert mit [Claude Code](https://claude.com/claude-code)
EOF
)"

PR-Vorlagenbeispiele

Feature-PR:

## 📝 Zusammenfassung

OAuth2-Authentifizierungsablauf mit Unterstützung für Google- und GitHub-Anbieter hinzufügen.

## 🔄 Änderungen

- ✨ OAuth2-Autorisierungscodeablauf mit PKCE hinzufügen
- 🔐 Sichere Token-Speicherung mit verschlüsselten Cookies implementieren
- 📝 Benutzerprofil-Synchronisation bei erstem Login hinzufügen
- 🎨 Login-UI mit Anbieter-Buttons aktualisieren

## ✅ Überprüfung

1. Lokal ausführen: `npm run dev`
2. `/login` besuchen und "Mit Google anmelden" klicken
3. OAuth-Ablauf abschließen
4. Überprüfen, ob das Benutzerprofil korrekt erstellt wurde
5. Token-Aktualisierung bei Seitenneuladung prüfen

```bash
# Testsuite
npm run test:auth

🔗 Quellen

Schließt #456
OAuth 2.1 RFC: https://datatracker.ietf.org/doc/html/rfc6749
Design-Dokument: docs/design/oauth2-integration.md


**Fehlerbehebungs-PR:**
```markdown
## 📝 Zusammenfassung

Speicherleck im Event-Handler beheben, das mit der Zeit erhöhte Speichernutzung verursacht.

## 🔄 Änderungen

- 🐛 Event-Listener, der nicht richtig entfernt wurde, beheben
- ✅ Bereinigung in componentWillUnmount hinzufügen
- 📝 Dokumentation zum Event-Handler-Lebenszyklus hinzufügen

## ✅ Überprüfung

1. Browser DevTools öffnen → Arbeitsspeicher
2. Heap-Snapshot erstellen
3. 10-mal durch die App navigieren
4. Einen weiteren Snapshot erstellen
5. Überprüfen, ob keine losgelösten DOM-Knoten vorhanden sind

## 🔗 Quellen

- Behebt #789
- Verwandtes Issue: #123

Schritt 5: Auf Code-Reviews warten

Warten, bis Code-Reviews abgeschlossen sind, bevor Kommentare geprüft werden:

echo "⏳ Warten auf Code-Reviews..."
sleep 180

Review-Kommentare abrufen

# Repo-Slug auflösen
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

# PRs auflisten
gh pr list

# PR-Details anzeigen
gh pr view <PR_NUMMER>

# Inline-Code-Review-Kommentare abrufen (Antworten ausfiltern, um nur Originale zu erhalten)
gh api repos/$REPO_SLUG/pulls/$PR_NUMMER/comments --jq '.[] | select(.in_reply_to_id == null) | {id: .id, path: .path, line: .line, body: .body}'

# Issue-Level-Kommentare abrufen (allgemeine PR-Kommentare)
gh api repos/$REPO_SLUG/issues/$PR_NUMMER/comments --jq '.[] | {id: .id, body: .body}'

# Review-Status abrufen
gh pr view $PR_NUMMER --json reviews --jq '.reviews[] | {state: .state, body: .body, author: .author.login}'

Schritt 6: Review-Kommentare auswerten und beheben

Jeden Kommentar kategorisieren

Kategorie	Aktion	Beispiele
Muss behoben werden	Code-Änderung erforderlich	Fehler, Sicherheitsprobleme, Logikfehler, kaputte Tests
Sollte behoben werden	Code-Änderung empfohlen	Code-Stil, Benennung, fehlende Fehlerbehandlung
Vorschlag	Optional, nach eigenem Ermessen	Alternative Ansätze, schönere Muster
Frage	Nur antworten, keine Code-Änderung	Prüfer fragt nach Klärung
Bereits erledigt	Nur antworten	Kommentar bezieht sich auf bereits behobenen Code

Prozess für jeden Kommentar

Die referenzierte Datei in der angegebenen Zeilennummer lesen
Die minimale Korrektur vornehmen, um das Feedback zu adressieren
Stagen und committen mit passendem Emoji-Commit
Die Kommentar-ID notieren für spätere Antwort

# Korrektur vornehmen
# ... Code-Änderungen ...

# Fix committen
git add <geänderte-dateien>
git commit -m "🐛 fix: Review-Feedback adressieren - Randfall behandeln"

Schritt 7: Fixes pushen und auf jeden Kommentar antworten

Nachdem alle Fixes committet wurden:

# Alle Fix-Commits pushen
git push

Vor dem Antworten den Fix-Hash berechnen:

FIX_HASH=$(git rev-parse --short HEAD)

Dann für jeden Kommentar antworten, die Shell-Variable $FIX_HASH und die numerische id aus Schritt 5 verwenden:

# Auf Inline-Review-Kommentar antworten
gh api repos/$REPO_SLUG/pulls/$PR_NUMMER/comments \
  --method POST \
  --field body="✅ Behoben in $FIX_HASH. <beschreiben, was tatsächlich geändert wurde>" \
  --field in_reply_to=$KOMMENTAR_ID

# Auf allgemeinen PR-Kommentar antworten (Hinweis: GitHub API erstellt einen neuen Top-Level-Kommentar, keine Thread-Antwort – dies ist eine API-Einschränkung)
gh api repos/$REPO_SLUG/issues/$PR_NUMMER/comments \
  --method POST \
  --field body="✅ Adressiert in $FIX_HASH. <beschreiben, was tatsächlich geändert wurde>"

Antwortformat:

Behebungen: ✅ Behoben in <kurzer_hash> — <was geändert wurde>
Fragen: 💡 <antwort>
Nicht umgesetzte Vorschläge: 🙏 Guter Vorschlag, aber <grund>. Gerne bei Bedarf erneut aufgreifen.

Schritt 8: Wiederholen – Erneut auf neues Feedback prüfen

Nach dem Pushen von Fixes:

# Kommentare erneut abrufen und mit bereits verarbeiteten IDs vergleichen
gh api repos/$REPO_SLUG/pulls/$PR_NUMMER/comments --jq '.[] | select(.in_reply_to_id == null) | .id'

Wenn neue Kommentar-IDs gefunden werden → ab Schritt 6 wiederholen
Wenn keine neuen Kommentare → mit Schritt 9 fortfahren

Häufige Review-Antworten

Kommentartyp	Antwortansatz
Code-Stil	Korrektur + `🎨 style:`-Commit
Fehlerbericht	Korrektur + `🐛 fix:`-Commit
Fehlende Tests	Tests hinzufügen + `✅ test:`-Commit
Dokumentation	Doku aktualisieren + `📝 docs:`-Commit
Leistung	Optimieren + `⚡️ perf:`-Commit
Umstrukturierung	Refaktorieren + `♻️ refactor:`-Commit

Schritt 9: PR-Status überwachen (UNSTABLE -> CLEAN)

Diese Überwachungsschleife verwenden, um zu warten, bis alle CI-Checks bestanden sind:

#!/bin/bash
PR_NUMMER="<PR_NUMMER>"

for i in {1..60}; do
  pr_status=$(gh pr view $PR_NUMMER --json mergeStateStatus --jq '.mergeStateStatus')

  if [ "$pr_status" = "CLEAN" ]; then
    echo "✅ Alle Checks bestanden! Bereit zum Merge."
    exit 0
  fi

  echo "⏳ Warten... ($i/60) - status: $pr_status"
  sleep 10
done

echo "❌ Timeout - Checks wurden nicht innerhalb von 10 Minuten bestanden"
exit 1

Mögliche Status:

UNKNOWN - Status noch nicht ermittelt
BEHIND - Branch liegt hinter dem Basis-Branch
BLOCKED - Blockiert durch fehlgeschlagene Checks
DIRTY - Merge-Konflikt
DRAFT - PR befindet sich im Entwurfsstatus
UNSTABLE - Checks wurden noch nicht bestanden
CLEAN - Alle Checks bestanden, bereit zum Merge

Schritt 10: PR mergen (Squash + Branch löschen)

gh pr merge <PR_NUMMER> --squash --delete-branch

Hinweis: Das Weglassen von --subject lässt GitHub auf den PR-Titel zurückfallen, der bereits das korrekte Emoji/Typ-Präfix enthält.

Merge-Optionen:

--squash - Alle Commits in einen zusammenfassen (empfohlen)
--merge - Mit vollständiger Commit-Historie mergen
--rebase - Commits auf den Basis-Branch rebasen
--delete-branch - Branch nach dem Merge löschen

Schritt 11: Lokale und entfernte Branches aufräumen

# Zum Default-Branch zurückwechseln
git checkout "$DEFAULT_BRANCH"

# Neueste Änderungen pullen
git pull origin "$DEFAULT_BRANCH"

# Lokalen Branch löschen
git branch -d feat/beschreibender-name

# Bei Bedarf mit Gewalt löschen
git branch -D feat/beschreibender-name

# Remote-Branch löschen (falls nicht bereits gelöscht)
git push origin --delete feat/beschreibender-name

Vollständiges Workflow-Skript

Hier ist ein vollständiges Skript, das den gesamten Workflow kombiniert (Überwachen, Beheben, Merge, Aufräumen):

#!/bin/bash
set -e

PR_NUMMER="<PR_NUMMER>"
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

# Schritt 5: Auf Reviews warten
echo "⏳ Warte 120 Sekunden auf Code-Reviews..."
sleep 180

# Schritt 6-8: Behebungsschleife (maximal 5 Iterationen)
PROCESSED_IDS=""
MAX_ITERATIONEN=5
iteration=0
while [ $iteration -lt $MAX_ITERATIONEN ]; do
  iteration=$((iteration + 1))
  KOMMENTAR_IDS=$(gh api repos/$REPO_SLUG/pulls/$PR_NUMMER/comments --jq '.[] | select(.in_reply_to_id == null) | .id')
  NEUE_IDS=$(comm -23 <(echo "$KOMMENTAR_IDS" | sort) <(echo "$PROCESSED_IDS" | sort) || true)

  if [ -z "$NEUE_IDS" ]; then
    echo "✅ Keine neuen Review-Kommentare."
    break
  fi

  echo "📝 Neue Review-Kommentare gefunden. Werden bearbeitet..."
  # (Claude Code wertet hier jeden Kommentar aus und behebt ihn)

  git push
  PROCESSED_IDS="${PROCESSED_IDS}
${NEUE_IDS}"

  echo "⏳ Warte auf CI und erneutes Review..."
  sleep 60
done

if [ $iteration -ge $MAX_ITERATIONEN ]; then
  echo "⚠️ Maximale Anzahl an Behebungsiterationen erreicht. Möglicherweise ist eine manuelle Überprüfung erforderlich."
fi

# Schritt 9: PR-Status überwachen
echo "🔍 Überwache Status von PR #$PR_NUMMER..."
HEAD_BRANCH=$(gh pr view $PR_NUMMER --json headRefName --jq '.headRefName')
for i in {1..60}; do
  pr_status=$(gh pr view $PR_NUMMER --json mergeStateStatus --jq '.mergeStateStatus')

  if [ "$pr_status" = "CLEAN" ]; then
    echo "✅ Alle Checks bestanden!"
    break
  fi

  echo "⏳ Warten... ($i/60) - status: $pr_status"
  sleep 10
done

# Schritt 10: PR mergen
echo "🔀 Merge PR #$PR_NUMMER..."
gh pr merge $PR_NUMMER --squash --delete-branch

# Schritt 11: Aufräumen
echo "🧹 Räume auf..."
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git branch -D "$HEAD_BRANCH" 2>/dev/null || true
echo "✅ Erledigt! Bereit für das nächste Feature."

Kurzreferenz-Befehle

Branch-Operationen

git checkout -b feat/feature-name    # Feature-Branch erstellen
git checkout "$DEFAULT_BRANCH" && git pull  # Mit Default-Branch synchronisieren
git b

In Ihrer bevorzugten KI fragen

Dokumentation