Git-Befehle, die man ausführt, bevor man den Code liest

 (piechowski.io)
89 Punkte von GN⁺ 21 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Beim Einstieg in eine neue Codebasis lässt sich durch Analyse der Git-Historie die Struktur des Projekts und seine Risikozonen erkennen, um die Erkundung effizient auszurichten
  • Durch das Auffinden der am häufigsten geänderten Dateien der letzten 12 Monate und die Kreuzanalyse von Änderungsfrequenz und Bug-Häufung lässt sich Hochrisiko-Code identifizieren
  • Über Verteilung der Beitragenden und Aktivitätstrends lassen sich Bus-Faktor, Wartungslücken und mögliche Wissensabbrüche prüfen
  • Anhand monatlicher Commit-Zahlen kann man Änderungen bei Entwicklungstempo und Teamdynamik verfolgen und über die Häufigkeit von Reverts und Hotfixes die Stabilität von Releases bewerten
  • Diese fünf Befehle sind ein praktisches Werkzeug für eine schnelle Diagnose des Projektzustands, noch bevor man eine einzige Codezeile öffnet

Fünf Git-Befehle, die man vor dem Lesen des Codes ausführt

  • Ein Ansatz zur Analyse einer neuen Codebasis, bei dem man noch vor dem Öffnen von Dateien mit der Git-Historie den Gesundheitszustand des Projekts diagnostiziert
    • Über die Commit-Historie lässt sich erkennen, wer den Code erstellt hat, wo sich Probleme konzentrieren und wie stabil das Team deployt

  • Was wird am häufigsten geändert?

    • Befehl: 
      git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    • Zeigt die 20 Dateien an, die im letzten Jahr am häufigsten geändert wurden
    • Diese Dateien sind oft diejenigen, die das Team nur ungern „anfasst“; wenn hohe Änderungsfrequenz (churn) und vermeidene Ownership zusammenkommen, werden sie zum größten Belastungsfaktor der Codebasis
    • Laut einer Studie von Microsoft Research (2005) haben metriken auf Basis der Änderungsfrequenz eine höhere Vorhersagekraft für Defekte als Komplexitätsmetriken
    • Durch Kreuzanalyse der Top-5-Dateien mit einem Befehl zur Bug-Häufung lassen sich Dateien mit vielen Änderungen und vielen Bugs als größtes Risiko identifizieren

  • Wer hat diesen Code gebaut?

    • Befehl: 
      git shortlog -sn --no-merges
    • Ordnet Beitragende nach Anzahl der Commits
    • Wenn eine Person mehr als 60 % ausmacht, besteht ein Risiko beim Bus-Faktor (bus factor)
    • Wenn der wichtigste Beitragende in den letzten 6 Monaten nicht aktiv war, ist eine Wartungslücke möglich
    • Wenn von 30 Beitragenden im letzten Jahr nur 3 aktiv waren, kann es durch Entwicklerwechsel zu einem Abriss von Wissen gekommen sein
    • Allerdings können Teams mit squash-merge-Strategie Autoreninformationen zugunsten der Person, die merged, verzerren; deshalb muss die Merge-Strategie geprüft werden

  • Wo häufen sich Bugs?

    • Befehl: 
      git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    • Ermittelt auf Basis von Commits mit Bug-bezogenen Keywords die Top 20 der Dateien mit Bug-Vorkommen
    • Durch Vergleich mit der Liste der häufig geänderten Dateien lässt sich Code, der oft geändert wird und oft kaputtgeht, als Hochrisiko-Code identifizieren
    • Die Genauigkeit hängt von der Qualität der Commit-Messages ab, ist aber selbst als grobe Karte der Bug-Dichte sehr nützlich

  • Beschleunigt das Projekt oder stagniert es?

    • Befehl: 
      git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
    • Über monatliche Commit-Zahlen lassen sich Aktivitätstrends visuell erfassen
    • Ein gleichmäßiger Rhythmus deutet auf ein gesundes Projekt hin
    • Wenn sich die Zahl der Commits innerhalb eines Monats halbiert, könnte Schlüsselpersonal das Team verlassen haben
    • Ein anhaltender Rückgang über 6 bis 12 Monate deutet auf nachlassende Teamdynamik hin; periodische Spitzen mit anschließender Stagnation sprechen für ein batch-orientiertes Release-Muster
    • Aus der Praxis gibt es Fälle, in denen ein CTO anhand eines Commit-Geschwindigkeitsdiagramms erkannte: „Das war der Zeitpunkt, an dem ein Senior Engineer gegangen ist.“
    • Diese Daten sind nicht nur Code-Daten, sondern Team-Daten

  • Wie oft ist das Team im Notfallmodus?

    • Befehl: 
      git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    • Misst die Häufigkeit von Reverts und Hotfixes
    • Einige Fälle pro Jahr sind normal, aber wenn das alle zwei Wochen passiert, ist das ein Signal für mangelndes Vertrauen in den Release-Prozess
    • Das kann auf tiefere Probleme hindeuten, etwa instabile Tests, fehlende Staging-Umgebungen oder komplizierte Rollback-Prozesse
    • Wenn das Ergebnis 0 ist, ist das Team entweder stabil oder die Commit-Messages sind ungenau
    • Krisenmuster werden deutlich sichtbar, und schon ihre Existenz reicht aus, um die Zuverlässigkeit einzuschätzen

Fazit

  • Diese fünf Befehle lassen sich in wenigen Minuten ausführen und geben noch vor dem Öffnen einer einzigen Codezeile eine Richtung vor, wo man mit dem Lesen beginnen sollte
  • So wird statt zielloser Erkundung am ersten Tag eine systematische Codeanalyse mit Fokus auf Problemzonen möglich
  • Dieses Vorgehen entspricht der ersten Stunde eines Codebase-Audits und leitet in den anschließenden Analyseprozess der nächsten Woche über

Verwandte Beiträge

1 Kommentare

 
GN⁺ 21 일 전
Hacker-News-Kommentare

  • Es werden Beispiele geteilt, wie sich Git-Analysebefehle in Jujutsu ersetzen lassen.
    Mit jj log lassen sich die in den letzten 12 Monaten am häufigsten geänderten Dateien, wichtige Mitwirkende, Stellen mit gehäuften Bugs, die Vitalität des Projekts und die Häufigkeit von Hotfixes prüfen.
    Die Syntax ist eher nah an einer Programmiersprache als an Shell-Skripten, dafür muss man sich weniger Flags merken.

    • Für mich wirkt Jujutsu wie das Nix der Versionsverwaltungssysteme.
      So wie Nix zwar cool ist, aber zusätzliche Komplexität mitbringt, fühlte sich auch Jujutsu an.
      Ich habe es ein paar Monate benutzt und bin dann zu Git zurückgekehrt, weil ich Git im Muskelgedächtnis habe und es überall verwendet wird.
    • Ich verstehe nicht, wie man sich all diese benutzerdefinierten Skriptsprachen merken soll.
      Schon wenn ich mir in jq nur die Array-Schleife merke, bin ich zufrieden, aber für so eine Syntax fehlt mir jedes Gefühl.
    • Sowohl jj- als auch Git-Befehle sind mir zu lang und zu komplex, um sie auswendig zu lernen.
      Wenn ich sie oft brauche, würde ich sie einfach per Alias abkürzen.
    • Ein Projekt ist nicht tot, nur weil es keine Commits gibt; das kann im Gegenteil bedeuten, dass es stabil ist.
      Es gibt zum Beispiel eine Bibliothek zur QR-Code-Erzeugung, die seit 10 Jahren keine Updates mehr bekommen hat und perfekt funktioniert.
      Man fragt sich dann fast, ob man sinnlose Commits per Bot hinzufügen sollte.
    • Ich will Git nicht programmieren, ich will einfach nur meine Arbeit erledigen.
      Deshalb bevorzuge ich gegenüber Tools wie Jujutsu eher klassische UNIX-Pipe-Befehle.
      Aus demselben Grund nutze ich Maven statt Gradle.

  • Ich fand es lustig, dass der Autor offenbar davon ausgeht, Entwickler würden gute Commit-Messages schreiben.
    In der Realität ist es meist eher auf dem Niveau von „changed stuff“.
    Leute wie ich, die Commit-Logs wichtig nehmen, sind in der Minderheit.
    Von KI erzeugte Commit-Messages könnten bei diesem Problem viel helfen.

    • Das ist ein Führungsproblem. Gute Teamleiter oder CTOs machen klar, welche Qualität sie bei Commit-Messages erwarten.
    • In Teams, die PRs per Squash mergen, wird oft der PR-Text zur Commit-Message, wodurch die Qualität besser ist.
    • In einem Squash-&-Merge-Workflow wird am Ende der PR-Titel zur entscheidenden Message.
      Entwickler können ihre Commit-Messages frei schreiben, weil sie später ohnehin niemand mehr liest.
    • Unser Team unterscheidet zwischen Core-Repos und Non-Core-Repos.
      Bei Core sind PR-Review und ausführliche Beschreibung Pflicht, bei Non-Core kann frei experimentiert werden.
      In Core-Repos sind Commit-Messages manchmal 20-mal länger als der Code, in Non-Core reicht eher „hope this works“.
    • Wenn Entwickler keine Commit-Messages schreiben, ist das ein Kulturproblem.
      In unserer Firma wird das gegenseitig eingefordert.

  • Ich habe solche Befehle auf mehreren Codebasen ausprobiert, und die Ergebnisse passten nicht zur Realität.
    Zum Beispiel war bei git shortlog -sn --no-merges die Person mit den meisten Commits teils schon längst nicht mehr im Unternehmen.
    Viele Commits bedeuten nicht automatisch einen großen Beitrag.

    • Deshalb bevorzuge ich Squash-and-Merge.
      Unnötig viele Commits bleiben nur im Feature-Branch erhalten, und auf main wird sauber gemergt.
    • Solche Befehle sind nützlich, wenn man problematische Projekte diagnostizieren will.
      Bei einer normalen Codebasis liefern sie meist nur wenig aussagekräftige Ergebnisse.
    • Ehrlich gesagt bezweifle ich, dass der Autor die Befehle wirklich selbst ausgeführt hat; es wirkt wie ein von einem LLM geschriebener Text.
    • Wenn ein automatisierter Workflow die Zugangsdaten einer einzigen Person nutzt, können die Statistiken verzerrt werden.
    • Ich habe in einer zentralen Codebasis eines Unternehmens ebenfalls mit Abstand die meisten Commits.
      Das liegt daran, dass ich das Projekt am Anfang aufgebaut habe; heute committen andere deutlich häufiger.

  • Die Aussage „Die am häufigsten geänderte Datei ist die Datei, die niemand anfassen will“ fand ich interessant.

    • Das klingt wie das Paradox vom „Restaurant, das so voll ist, dass niemand hingeht“.
    • In meinem Test waren die am häufigsten geänderten Dateien eher automatisch erzeugte Dateien oder langweilige Dinge wie Einstiegspunkte.
    • Solche Befehle brauchen Warnhinweise.
      Wenn man aus dem bloßen Output direkt Schlussfolgerungen zieht, wirkt man eher töricht.
      Tatsächlich zeigen sie oft nur, an welchen Features im letzten Jahr gearbeitet wurde.
    • Wenn man Churn (Änderungshäufigkeit) und Complexity (Komplexität) zusammen betrachtet, wird es viel nützlicher.
      Wirklich problematisch sind die Bereiche, in denen beides hoch ist.
      Wenn sich solche Zonen ansammeln, fällt irgendwann der Satz: „Wir sollten die App von Grund auf neu schreiben.“
    • Dateien, vor denen sich Leute fürchten, sind meist unverzichtbare und zugleich komplexe Dateien.
      Jeder muss sie ändern, aber sie sind so groß, dass sie schwer zu handhaben sind.

  • Ich habe mir in Git einen Summary-Alias gebaut, der Branch-Zusammenfassung, Commit-Anzahl, Anzahl der Autoren, Dateianzahl und mehr auf einmal ausgibt.
    Die Idee stammt von GitAlias/gitalias.

    • Ich frage mich, warum das als .gitconfig-Funktion geschrieben wurde; als einfaches git-summary-Skript wäre es doch unkomplizierter.
    • Dass man solche Befehle jedes Mal von Hand eintippt, wirkt wieder wie ein von KI geschriebener Text; jemand mit Erfahrung würde dafür Aliase wiederverwenden.
    • Nettes Skript, aber in meiner Umgebung gibt es keinen Befehl wie log-of-count-and-email.
    • Vielleicht wäre es gut, lokal eine man-Page dafür anzulegen.

  • Im Regex sollte man Wortgrenzen (\b) hinzufügen.
    Sonst kann zum Beispiel „bug“ innerhalb von „debugger“ zu falschen Treffern führen.
    Ein korrigiertes Beispiel wäre:
    git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

    • Auf macOS wird \b nicht unterstützt, deshalb sollte man statt -E die Perl-Regex-Option -P verwenden.
      Dann geht es in der Form git log -i -P --grep="\b(...)\b".
    • Bei uns muss man auch das Wort „rollback“ filtern, weil wir es in anderem Sinn verwenden.
    • Guter Hinweis, das macht es deutlich präziser.

  • Wenn man Squash-Merge nicht nutzt, kann die Person mit den meisten Commits sogar der chaotischste Entwickler sein.
    Ich hatte früher einmal so jemanden im Team; er änderte immer wieder dieselbe Datei und wurde am Ende entlassen.
    Squash ist eine gute Methode, um solche Probleme zu kaschieren.

  • Einfache Commit-Anzahl-Statistiken sind schwer vertrauenswürdig.
    Manche committen nur perfekt getesteten Code, andere committen ständig zeilenweise.
    Der Wert eines einzelnen Commits kann sich je nach Person um das Hundertfache unterscheiden.

    • Dem Autor ging es aber darum, Veränderungstrends zu betrachten.
      Die Änderungsrate ist aussagekräftiger als der absolute Wert.

  • Dieser Analyseansatz erinnert an Adam Tornhills „Your Code as a Crime Scene“.
    Original-Link
    Es ähnelt auch dem Konzept des Developer’s Legacy Index.

    • Ich mochte Tornhills frühe Texte zu C, schön, das wiederzusehen.

  • Es wäre besser gewesen, wenn der Autor die Ergebnisse der einzelnen Befehle direkt gezeigt hätte.
    Beispielausgaben wären überzeugender gewesen als bloße Erklärungen.

    • Auch ich fand, dass der Text ein wenig nach KI klang, aber ich habe trotzdem fünf neue Befehle gelernt, also war es nicht schlecht.