Übersicht

git bisect start
git bisect good <commit>
git bisect bad <commit>
git bisect run <script>
git bisect reset

Beschreibung

Der git bisect-Befehl führt eine Binärsuche durch die Commit-Historie durch, um genau den Commit zu identifizieren, der einen Bug einführte. Sie beginnen damit, einen bekannt-schlechten Commit (oft HEAD) und einen bekannt-guten Commit (vielleicht einen Release-Tag) zu markieren, dann checkt Git einen Mittelpunkt aus und bittet Sie, zu testen. Sie antworten "good" oder "bad", Git verkleinert den Bereich, und Sie wiederholen, bis der schuldige Commit gefunden ist.

Wenn Sie einen automatisierten Test oder Reproducer haben, automatisiert git bisect run den gesamten Prozess — Git ruft Ihr Skript bei jedem Schritt auf. Das Bisecten durch tausend Commits dauert üblicherweise etwa zehn Iterationen.

Im täglichen Einsatz integriert sich git bisect eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git bisect --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git bisect mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git bisect hilft, alle drei zu vermeiden.

Häufige Optionen

Unterbefehl	Beschreibung
start	Beginnt eine Bisect-Sitzung.
good / bad	Markiert den aktuellen (oder angegebenen) Commit.
skip	Markiert einen Commit als nicht testbar.
run <cmd>	Automatisiert durch Ausführen eines Befehls (Exit 0 = good, Nicht-Null = bad).
reset	Beendet die Sitzung und kehrt zum ursprünglichen Branch zurück.
log	Zeigt das Bisect-Log.
visualize	Zeigt verbleibende verdächtige Commits an.

Beispiele

git bisect start
    git bisect bad HEAD
    git bisect good v1.5.0
    # Git checkt einen Mittelpunkt aus; testen, dann:
    git bisect good   # oder: git bisect bad

    git bisect run npm test
    # Voll automatisiert: npm-test-Exit-Codes steuern die Suche

    git bisect reset
    # Zum ursprünglichen Branch zurückkehren

Häufige Fehler

Vergessen, git bisect reset auszuführen, lässt Sie im Detached-HEAD-Zustand. Einen Commit als "good" zu markieren, wenn der Bug intermittierend ist, führt Bisect in die Irre — verwenden Sie stattdessen skip. Stellen Sie sicher, dass Ihr Test-Skript Exit-Code 125 zurückgibt, um "skip" zu signalisieren, falls der Build selbst bei diesem Commit kaputt ist.

Verwandte Befehle

git log, git blame, git show, git checkout