Skip to content
NeuralSkills
Code-Review

Git-Historie-Review

Git-Historie pruefen: Commit-Qualitaet, Branch-Strategie, Merge-Hygiene und aussagekraeftige Aenderungsdokumentation.

Einsteiger Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Die Git-Historie ist das institutionelle Gedaechtnis eines Projekts — aber die meisten Teams behandeln sie als Muellhalde. Commits wie “fix stuff,” “WIP” und “final final v3” sagen zukuenftigen Entwicklern nichts. Feature-Branches leben monatelang, sammeln Dutzende Merge-Commits und verschleiern die eigentliche Arbeit. Wenn ein Produktionsbug auftritt und jemand git bisect startet, ist es unmoeglich, die brechende Aenderung zu isolieren.

Der Prompt

Pruefe die folgende Git-Historie. Handle als Staff Engineer, der die Versionskontrollpraktiken des Teams auf Klarheit und Nachvollziehbarkeit bewertet.

GIT LOG:
[Ausgabe von git log --oneline --graph -30 einfuegen]

AKTUELLE DIFFS (optional):
[Relevante Commit-Diffs einfuegen]

Bewerte in diesen Dimensionen:

1. **Commit-Nachrichten**
   - Erklaeren Nachrichten WAS sich geaendert hat und WARUM?
   - Gibt es ein konsistentes Format (Conventional Commits, Praefix-Tags)?
   - Sind Nachrichten im Betreff knapp (<72 Zeichen), im Body detailliert?
   - Referenzieren Nachrichten Issue-/Ticket-Nummern?

2. **Commit-Granularitaet**
   - Ist jeder Commit eine einzelne logische Aenderung?
   - Gibt es leere Commits, WIP-Commits oder "Ups"-Fixup-Commits?
   - Waere `git bisect` effektiv (jeder Commit baut und Tests bestehen)?

3. **Branch-Strategie**
   - Sind Feature-Branches kurzlebig (innerhalb von Tagen gemergt)?
   - Ist das Branching-Modell klar (Trunk-Based, GitFlow, GitHub Flow)?
   - Sind Branch-Namen aussagekraeftig (feat/, fix/, refactor/)?

4. **Merge-Hygiene**
   - Sind Merge-Commits sauber?
   - Nutzt das Team Rebase oder Squash fuer saubere Historie?
   - Gibt es Merge-Commits, die versehentlich vorherige Aenderungen reverten?

5. **Sensible Daten**
   - Wurden Secrets, Credentials oder .env-Dateien jemals committet?
   - Wurden grosse Binaerdateien committet, die in LFS sein sollten?

6. **Nachvollziehbarkeit**
   - Kann man eine Codeaenderung zu einer Anforderung zurueckverfolgen?
   - Sind PRs mit Issues verlinkt?

Fuer jedes Problem liefere:
- **Commit(s)**: SHA oder Nachricht
- **Problem**: Warum dies die Wartbarkeit beeintraechtigt
- **Schweregrad**: Audit-Risiko / Verwirrung / Stil
- **Fix**: Korrigierte Praxis oder rueckwirkende Bereinigung

Beispielausgabe

## Git-Historie-Review: 4 Probleme gefunden

### Verwirrung: Nichtssagende Commit-Nachrichten
Commits: "fix" (x7), "update" (x4), "WIP" (x3)
Fix: Conventional Commits einfuehren:
  feat(auth): Passwort-Zuruecksetzung hinzufuegen (#234)
  fix(cart): Doppelbelastung bei Retry verhindern (#567)

### Audit-Risiko: Secret committet und entfernt
Commit: abc123 — .env mit DATABASE_URL committet, in def456 geloescht.
Problem: Secret existiert weiterhin in der Git-Historie.
Fix: DATABASE_URL-Credential sofort rotieren. git-filter-repo zum Bereinigen verwenden.

Wann verwenden

Beim Onboarding in ein Projekt, bei Team-Prozessreviews oder wenn git bisect bei der Regressionsfindung versagt. Wertvoll als periodisches Audit (vierteljaehrlich), um schlechte Gewohnheiten zu erkennen, bevor sie zur Teamkultur werden.

Profi-Tipps

  • Git-Graphen einbeziehen — git log --oneline --graph --all -30 nutzen, um Branch-Struktur zu zeigen.
  • Rueckwirkend auf Secrets pruefen — “Scanne diesen Git-Log auf Commits, die Secrets enthalten koennten.”
  • Konventionen frueh etablieren — “Generiere einen CONTRIBUTING.md-Abschnitt mit Commit-Nachricht-Richtlinien und Branch-Namensregeln.”