git bisect
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.
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 siebreakme.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?
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.