Programmierpraktikum SoSe 2024, Bachelor Informatik, FU Berlin
ProPra2024 > Debugging > Debuggingtools > gitbisect

git bisect

Idea

Ziel

  • Ich weiß, wie ich mittels git bisect prüfe, in welchem vorherigen Commit sich ein Bug eingeschlichen hat.
  • Ich verstehe, in welchen Fällen git bisect zum Debuggen nützlich ist.
  • Ich verstehe, welche Aufgabe git bisect beim Debuggen übernimmt.

Hintergrund

Stellen Sie sich vor, Ihre Codebasis hat eine Million Zeilen Code. Und nun entdecken Sie ein Versagen, das offenbar nichts mit dem zu tun hat, woran Sie zuletzt gearbeitet haben, sondern der Defekt muss schon länger in der Codebasis schlummern.

Wenn man eine gute Versionshistorie hat, kann man die benutzen, um den Defekt einzukreisen, indem man einen automatisierten Test schreibt, der das Versagen zeigt, und dann den jüngsten Commit X sucht, bei dem das Versagen auftritt. Beim letzten Commit vor X ist das jetzt defekte Verhalten also noch intakt. Dann müsste doch Commit X den Defekt enthalten?

Und wenn in jedem Commit nur wenig geändert wird, ist ein Defekt innerhalb dieser Änderungen viel leichter zu lokalisieren als in der Codebasis insgesamt.

Das ist die Grundidee von git bisect, das wir in dieser Aufgabe kennenlernen wollen.

Leider ist "automatisierter Test" in diesem Zusammenhang viel schwieriger als es klingt, denn die Codebasis ist ja bei jedem Commit anders (und bei sehr alten Commits sehr anders). Außerdem gibt es Commits, die keinen konsistenten Zustand bieten, den man überhaupt sinnvoll testen kann. Deshalb ist der Test in vielen Fällen dann doch manuell.

Loose

Arbeitsschritte

Beschäftigen Sie sich mit der Dokumentation von git bisect.

  • Legen Sie das Dokument gitbisect.md an.
  • Fügen Sie in diesem Dokument die Überschrift Wie funktioniert git bisect? ein.
  • 1 Beschreiben Sie den allgemeinen Ablauf von git bisect.
  • 2 Beschreiben Sie, wie man einen git bisect-Prozess startet.
  • 3 Beschreiben Sie, was die Argumente "good" und "bad" in git bisect bedeuten.
  • 4 Beschreiben Sie, wie ein Skript aussehen muss, anhand dessen git bisect automatisiert prüft, ob ein Commit fehlerhaft ist oder nicht. Geben Sie auch an, wie die Rückgabewerte aussehen müssen.
  • 5 Gibt es einen Befehl in git bisect, der ohne ein zusätzliches Test-Skript automatisiert Ihre Commits prüfen kann? Wenn ja, wie lautet er? Welche Voraussetzung muss dafür gegeben sein?
  • 6 Geben Sie den Befehl an, mit dem Sie den git bisect-Prozess beenden.
  • 7 Überlegen Sie: Sie könnten auch einfach so den Defekt reparieren und die Commit History ignorieren. Warum kann es aber nützlich mittels git bisect herauszufinden, wann der Defekt eingetreten ist?

Als Nächstes versuchen wir git bisect an einem Beispiel-Repo einzusetzen.

  • Klonen Sie dieses Repo.
  • In dem Repo befinden sich zwei Dateien:
  • ein Python-Skript, squares.py, welches als Eingabe eine Zahl bekommt und diese quadriert
  • und ein Bash-Skript, breakme.sh, welches eine git-History für uns erstellt.
  • Wechseln Sie im Terminal in das Verzeichnis des Repos.
  • Fügen Sie in gitbisect.md eine weitere Überschrift ein, Übung. Fügen Sie die folgenden Arbeitsschritte unter dieser Überschrift ein.
  • 1 Vergewissern Sie sich, dass der Aufruf python squares.py 2 das richtige Ergebnis liefert.
  • Führen Sie das Skript breakme.sh aus.
  • 2 Vergewissern Sie sich, dass der Aufruf python squares.py 2 jetzt nicht mehr funktioniert.
  • 3 Starten Sie den git bisect-Prozess.
  • 4 Wählen Sie als "good commit" den Hash 312c137 aus (das ist der Commit bevor sie breakme.sh benutzt haben).
  • 5 Wählen Sie als "bad commit" HEAD aus.
  • 6 Führen Sie den git bisect-Prozess automatisiert aus.
  • 8 Welche der beiden Möglichkeiten zur Automatisierung haben Sie gewählt? Begründen Sie.
  • 7 Sie haben nun den fehlerhaften Commit gefunden. Beenden Sie den git bisect-Prozess.
  • 9 Wie würde jetzt das weitere Vorgehen aussehen?
Information

Abgabe

Geben Sie ein Markdown-Dokument ab mit knappen Antworten zu den oben gestellten Fragen 1, 2, … Geben Sie diese Marker mit an.
Geben Sie ggf. Beispiele oder benutzte Quellen an.

Geben Sie ein Kommandoprotokoll ab, das genau nur die Eingaben und Ausgaben der obigen Kommandos 1, 2, … enthält. Entfernen Sie vor Abgabe eventuelle Fehlversuche und sonstige zusätzliche Kommandos aus dem Protokoll.