`git who` – Wer hat diesen Code geschrieben?!

 (github.com/sinclairtarget)
8 Punkte von GN⁺ 2025-03-20 | 1 Kommentare | Auf WhatsApp teilen
  • git-who ist ein CLI-Tool, um Verantwortliche für ganze Komponenten oder Subsysteme einer Codebasis zu finden
  • Anders als git blame arbeitet git-who auf Dateibaum-Ebene und identifiziert so Code-Autoren
  • Es bietet drei Subcommands, von denen jedes eine andere Perspektive auf die Urheberschaft in einem Git-Repository liefert

    • table

      • Standardmäßig wird eine Tabelle ausgegeben, die die Beiträge aller Autoren zusammenfasst, die im Repository Commits erstellt haben
      • Durch Angabe eines Pfads können nur Commits gefiltert werden, die Dateien unter diesem bestimmten Pfad betreffen
      • Durch Angabe eines Branch-Namens, Tag-Namens oder eines „commit-ish“ können nur Commits gefiltert werden, die von einem bestimmten Commit aus erreichbar sind
      • Mit den Flags -m, -c, -l, -f kann die Tabelle nach verschiedenen Metriken sortiert werden

    • tree

      • Gibt den Dateibaum aus, wobei jeder Knoten den Autor mit dem größten Beitrag für den jeweiligen Pfad anzeigt
      • Mit dem Flag -a können alle Dateien annotiert werden
      • Unterstützt die Flags -l, -f, -m, -c

    • hist

      • Gibt ein Histogramm/eine Zeitleiste der Commit-Aktivität aus und zeigt so die Beitragsgeschichte des Repositorys
      • Unterstützt die Flags -l und -f
  • Zusätzliche Optionen zum Filtern von Commits
    • Mit den Optionen --author und --nauthor können einzuschließende oder auszuschließende Autoren angegeben werden
    • Mit den Optionen --since und --until können Commits vor oder nach einem bestimmten Datum gefiltert werden
  • Caching: Daten werden repositoryspezifisch in XDG_CACHE_HOME zwischengespeichert. Um das Caching zu deaktivieren, setze GIT_WHO_DISABLE_CACHE=1
  • Wenn das git-who-Binary im Pfad installiert ist, kann git who ohne zusätzliche Konfiguration ausgeführt werden. Bei Installation unter einem anderen Namen oder für eine explizite Konfiguration kann ein Alias in den Git-Einstellungen hinzugefügt werden
  • Wenn im Git-Repository eine .mailmap-Datei vorhanden ist, berücksichtigt git who diese und zählt Commits derselben Person zusammen

  • Metriken

    • Anzahl der Commits: Zeigt die Anzahl der Commits an, die den Pfad geändert haben
    • Anzahl der Dateien: Zeigt die Anzahl der eindeutigen Dateien an, die vom Autor geändert wurden
    • Hinzugefügte Zeilen und entfernte Zeilen: Zeigen die Anzahl der Zeilen an, die im Pfad hinzugefügt oder entfernt wurden

  • Unterschiede zu git blame

    • git blame identifiziert für jede Zeile den Commit, der sie in den Code des Working Tree eingeführt hat, während
    • git who einen Teil des Commit-Logs untersucht und Beiträge aggregiert
    • Die beiden Tools arbeiten auf unterschiedlichen Ebenen und liefern unterschiedliche Informationen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-20
Hacker-News-Kommentare

  • Im Zusammenhang mit der Analyse „Wer hat vim geschrieben?“ kann es je nach Workflow so aussehen, als hätten interne Mitwirkende mehr beigetragen

    • Wenn Patches oder Pull Requests vor dem Merge von internen Mitwirkenden neu formatiert werden, kann dieselbe Arbeit doppelt gezählt werden oder nur der Person zugerechnet werden, die die Neuformatierung vorgenommen hat
    • Die Ergebnisse sind nicht falsch, aber man sollte vorsichtig sein, wenn man ohne Prüfung des Beitragsprozesses Bedeutung aus ihnen ableitet

  • Das Tool ist wirklich großartig. Ich habe es kurz vor Tagesende ein wenig ausprobiert

    • Meine persönliche Wunschliste ist wie folgt
      • Blame-basierte Statistiken. Es ist schön, die Beiträge von Bob und Alice zu sehen, aber nützlicher wäre es, die tatsächlichen Eigentümer von Modulen/Dateien zu zeigen
      • Unterstützung für musterbasierte Include-/Exclude-Regeln. Ich möchte zum Beispiel keine Statistiken für JSON-Dateien sehen, die in Tests verwendet werden, oder für automatisch generierte Dateien
      • Unterstützung für Konfigurationsdateien. Es wäre schön, wenn es eine TOML-basierte Datei gäbe, in der man bevorzugte Einstellungen im Git-Repository speichern kann
      • Bessere Paketierung. Zum Beispiel enthält das Linux-Tarball von v0.6 Apple-bezogenen „Müll“, und GNU tar warnt vor einer Nichtübereinstimmung im Archivformat

  • Viele Leute missverstehen git blame. Es geht nicht darum, wer etwas gemacht hat, sondern welcher Commit die Ursache ist

  • git-who kann als git who aufgerufen werden. Dazu muss man in der globalen Git-Konfiguration einen Alias setzen

    • Es funktioniert auch ohne Alias. Standardmäßig sucht git whatever im Pfad nach git-whatever und führt es aus

  • Ich nutze als Low-Tech-Version den Alias „nerdwars“, um git shortlog -ns --no-merges auszuführen. Das ist eine gute Methode, um die Hauptbeitragenden eines Projekts zu erfassen

  • GitLab/GitHub sollten eine Funktion hinzufügen, die bei eingereichten Merge Requests automatisch eine E-Mail an den letzten Autor der geänderten Codezeilen sendet

  • Dieses Tool ist hervorragend. Ich verwende git-blame-basierte Buchführung, um bei jedem Release der App die Menge an von KI und von Menschen geschriebenem Code zu verfolgen

    • Das „Blame-Skript“ wird langsamer, je größer das Repository wird. Ich habe versucht, Caching hinzuzufügen
    • Ich frage mich, ob geplant ist, eine Funktion hinzuzufügen, mit der sich Statistiken auf Basis von Dateimustern einschränken lassen

  • tig ist ein großartiges TUI-Git-Frontend und hat das wunderschöne Subkommando tig blame

  • Was in Git fehlt, sind nicht die Anzahl der von einem Entwickler geschriebenen Zeilen oder die Anzahl der Commits. Eher Dinge wie

    • Wer hat diese Zeile gelöscht
    • Wem gehört diese Methode

  • Manche Leute committen mit zwei verschiedenen E-Mail-Adressen. Zum Beispiel verwenden sie auf dem Heimcomputer und auf dem Arbeitscomputer jeweils eine andere Adresse. Es wäre gut, wenn man diese als identisch definieren könnte