Veröffentlicht am 07-05-2019

Git Bisect und die Jagd nach schlechten Commits

Eine Methode, um problematische Commits in großen Codebasen zu finden.

gojek.jobs

Git ist das am häufigsten verwendete verteilte Versionskontrollsystem. Mit Hilfe von git kann man leicht mit anderen zusammenarbeiten. Falls Sie mit dem Begriff nicht vertraut sind, habe ich ihn in einem anderen Beitrag näher ausgeführt

Fangen wir also mit dem Problem an:

Angenommen, Sie arbeiten an einer großen Codebasis mit vielen Mitarbeitern, die an demselben Projekt arbeiten, und jede Menge Commits pro Tag. Stellen Sie sich vor, Sie wären für eine Woche Urlaub gegangen. Wenn Sie zurückkommen, stellen Sie fest, dass das Produkt (das beim Verlassen gut funktionierte) nun einige Probleme aufweist.

Wie bereits erwähnt, ist es eine riesige Codebasis. Sie wissen nicht, welches Modul für das unerwünschte Verhalten verantwortlich ist.

Was wirst du tun?

In diesem Beitrag werde ich eine mögliche Lösung für dieses Problem erläutern. Einer meiner Lieblingsgit-Befehle - git bisect.

Sortierung zwischen gut und schlecht

Um auf das frühere Problem zurückzukommen, haben Sie jetzt eine von drei Möglichkeiten:

Option 1

Rufen Sie ein Treffen aller Mitwirkenden an und fragen Sie, wie dies geschehen ist.

Es kann Fälle geben, in denen dieses Verhalten durch zwei Änderungen verursacht wird, die Bestandteil mehrerer Commits von verschiedenen Personen sind (deren individuelle Änderungen gut funktionierten).

Meetings sind auch zeitaufwändig.

Option 2

Sie verwalten bereits den Commit-Verlauf. Warum prüfen Sie nicht jedes Commit und suchen nach der Ursache.

Was aber, wenn hunderte von Commits dazwischen liegen, wird die Überprüfung jedes Commits wirklich hart, langweilig und zeitaufwändig.

Option # 3

Binäre Suche für Commits ausführen

(Yup! Der gleiche Suchalgorithmus, den Sie an der High School gelernt haben)

Dies ist, wo git bisect ins Bild kommt. Es kann Ihnen dabei helfen, das spezifische Commit zu finden, das durch die Iteration von Commits auf eine binäre Suche gebrochen wurde. Sie müssen also jetzt nur noch Log (N) Commits anstelle von N Commits überprüfen (wie in Option 2 beschrieben).

Klingt gut, wie benutze ich es?

Halten Sie Ihren Commit Hash (SHA) bereit, auf dem:

  • Wenn etwas in Ordnung ist, nennen wir es gut
  • Wenn es sich nicht richtig verhält, nennen wir es schlecht

(Im schlimmsten Fall kann es sich um Start- und End-Commits des gesamten Projekts handeln.)

Erinnere dich an drei Dinge:

git bisect start BAD GOOD, wobei BAD und GOOD die Hinweise auf schlechtes und gutes Commit sind.

Verhalten prüfen, wenn es gut ist

Gib git bisect gut ein

sonst,

Gib git bisect schlecht ein

und wiederholen Sie den obigen Befehl, bis Sie SHA des ersten fehlerhaften Commits im Terminal so finden

<… Sha…> ist das erste schlechte Commit

Verwenden Sie git bisect reset zum Zurücksetzen und zum Zurückkehren in den ursprünglichen Zustand (von git bisect start).

In der Zwischenzeit können Sie auch die Protokolle der binären Suche, die Sie ausführen, mithilfe von git bisect log abrufen.

Eine Darstellung von Git-Bisekt in Aktion.

Nehmen wir ein Beispiel:

Hier haben wir ein Modul zur Berechnung der Fläche und des Umfangs verschiedener Polygone. (github repo)

Es folgt die Ausgabe des git-Protokolls (im Wesentlichen Commit-Historie).

Geschichte begehen

Wenn ich nun Tests mit dem aktuellen HEAD erneut durchführe, schlagen sie fehl.

Aber warte, ich weiß, dass diese beim Festschreiben vorbei waren:

Wie oben beschrieben, gibt es drei Optionen, um das Täter zu finden, bei dem die Tests fehlgeschlagen sind.

Gehen wir mit Option 3, der binären Suche, d.

Hier ist das schlechte SHA 3f5dedf und das gute SHA ist 861b6e0 (lass uns anfangen zu halbieren)

Der obige Befehl wird automatisch zu 5fcc576 ausgecheckt

Lassen Sie uns nun die Tests erneut ausführen.

Sie sind erneut fehlgeschlagen. Dies bedeutet, dass 5fcc576 auch ein schlechtes Commit ist. Also gehen wir mit git bisect schlecht.

Das Ergebnis des obigen Befehls wird automatisch zu 88ca0bd geprüft.

Tests erneut ausführen.

Scheitert immer noch, daher ist auch dieses Commit schlecht (also müssen wir mit git bisect schlecht gehen)

Überprüfen Sie jetzt erneut auf ab36264.

Erfolg! Sie sind bestanden

In der Zwischenzeit können wir das Bisect-Protokoll auch mit Hilfe von git bisect log überprüfen.

ab36264 ist ein gutes Commit.

Und hier sagt uns git, dass 88ca0bd866aeeb91b6b3f8c644b754068779488e der Schuldige ist.

Wenn wir mit Option # 2 gegangen wären, hätten wir unsere Tests ~ 8-mal ausgeführt, aber mit git bisect liefen wir nur 3-mal. Dies ist hilfreich, wenn Sie viele Tests haben und deren Ausführung sehr lange dauert.

Und ja! Mit minimalem Aufwand stellten wir fest, dass das Commit fehlschlug. Es kann auch verwendet werden, um die Ursache des Fehlers zu finden.

Lesen Sie mehr über Git Bisect unter https://git-scm.com/docs/git-bisect

Ich liebe es, Fehler zu beheben und fand git bisect sehr hilfreich, vor allem um das Commit zu finden, das den Fehler eingeführt hat.

Ich hoffe, es wird Ihnen auch gefallen!

Bauen Sie weiter auf & debuggen

(Anmerkung: Zweck des Codes war nur die Erklärung von git bisect, sonst nichts)

Bei GOJEK ist zu jeder Zeit viel los. Neben dem Transport helfen wir unseren Kunden auch, sich mit ihren Lifestyle-Services um sich selbst, ihren Besitz und ihr Zuhause zu kümmern. All dies wird von einem der größten JRuby-, Java- und Go-Cluster in Südostasien unterstützt. Willst du mit uns arbeiten? Schau dir gojek.jobs an und lass uns zusammen großartige Dinge bauen.

gojek.jobs

Siehe auch

Lernen Sie 50inTech @ VivaTech kennenMein unternehmerischer Journalismus-Achterbahn-ÜberlebensplanDer einfache Grund, warum Facebook nicht behoben werden kannHolochain & Holo Weekly Roundup 08 - Woche bis zum 11. Mai