git bisect Das breakende Commit ohne 500 Log-Zeilen zu lesen finden

Sie haben 50 Commits in zwei Wochen gepusht. Etwas ist irgendwo kaputt gegangen. Ein Test, der drei Wochen vorher erfolgreich war, scheitert jetzt. git log --oneline zeigt 200 Zeilen, die Sie nicht lesen möchten.

Sie haben Optionen: Sie starren auf die Diffs, bis Ihre Augen bluten, git checkout zufällige Commits manuell testen oder das Werkzeug zu verwenden, das seit 2007 in git enthalten ist und mit jeder Installation kommt.

git bisect führt eine binäre Suche durch Ihre Commit-Geschichte durch. Sie markieren einen Commit als defekt und einen als funktionstüchtig, und git checkout die Commits dazwischen – die Suchfläche wird dabei halbiert. Um einen Schuldigen in 500 Commits zu finden, benötigen Sie etwa 9 Schritte. Die meisten Entwickler verwenden es nie.

Wie es funktioniert

Der gesamte Workflow beginnt mit drei Befehlen:

git bisect start
git bisect bad                 # current state is broken
git bisect good v2.4.0         # last known-good tag or commit hash

Git checkt aus einem Commit mittig zwischen diesen beiden Punkten aus. Sie testen, ob das Problem existiert, und geben dann Rückmeldung:

git bisect good   # bug is NOT present here
# or
git bisect bad    # bug IS present here

Git schneidet den Bereich ab und wählt den nächsten Mittelpunkt. Wiederholen Sie, bis es Ihnen sagt abc1234 is the first bad commit. Sobald Sie fertig sind:

git bisect reset  # returns you to your original branch

Keine speziellen Flags, keine Konfiguration, keine Plugins. Funktioniert in jedem Repository, auf jeder git-Version, die Sie wahrscheinlich installiert haben.

Eine echte Bisect-Sitzung (angewiesen)

Hier ist eine vollständige Sitzung. Eine Funktion, die korrektes JSON zurückgab, begann nach einigen kürzlichen Refaktorierungen, null zurückzugeben – kein offensichtlicher Schuldige in den letzten Commits:

$ git bisect start
$ git bisect bad HEAD              # current commit is broken
$ git bisect good 3f8a12b          # commit from 2 weeks ago, worked fine

Bisecting: 24 revisions left to test after this (roughly 5 steps)
[c9e41f0] Refactor: extract auth middleware

$ npm test -- --grep "parseResponse"   # ← run your check here
# FAIL
$ git bisect bad

Bisecting: 12 revisions left to test after this (roughly 4 steps)
[a77b2d1] Fix: update retry logic in fetch wrapper

$ npm test -- --grep "parseResponse"
# PASS
$ git bisect good

Bisecting: 6 revisions left to test after this (roughly 3 steps)
[91e0bc3] Refactor: consolidate response handlers

$ npm test -- --grep "parseResponse"
# FAIL
$ git bisect bad

Bisecting: 2 revisions left to test after this (roughly 2 steps)
[b44c19f] Chore: remove deprecated serialization helpers

$ npm test -- --grep "parseResponse"
# FAIL
$ git bisect bad

Bisecting: 1 revision left to test after this (roughly 1 step)
[8d3e77a] Fix: normalize response envelope for new API version

$ npm test -- --grep "parseResponse"
# PASS
$ git bisect good

91e0bc3e1f4d is the first bad commit
commit 91e0bc3e1f4d
Author: Dev <dev@example.com>
Date:   Mon Apr 14 11:23:07 2026

    Refactor: consolidate response handlers

 src/http/response.js | 14 +++---

$ git bisect reset   # ← always do this when done

5 Schritte über einen 50-Commit-Bereich. Der Commit „response handlers zusammenfassen“ hatte eine Serialisierungsaufgabe still und leise entfernt, die von etwas am Ende abhängig war. Ohne Bisect hätten Sie eine Stunde Diffs gelesen.

Automatisierung

Wenn Sie das Prüfverhalten als Skript ausdrücken können – mit 0 für „gut“ und nicht-null für „schlecht“ – kann git bisect vollständig ohne menschliche Eingabe laufen:

git bisect start
git bisect bad HEAD
git bisect good v2.4.0
git bisect run npm test -- --grep "parseResponse"

Git checkt jeden Mittelpunkt aus, führt das Skript aus und gibt den ersten schlechten Commit zurück. Für Tests, die unter 10 Sekunden dauern, ist dies schnell genug, um zu gehen und später die Antwort zu erhalten.

Semantik der Exit-Codes für das Ausführungs-Skript:

• 0 — Commit ist gut
• 1–124 — Commit ist schlecht
• 125 — überspringe diesen Commit (aufgebauter Build, kann nicht getestet werden)

Verwenden Sie 125 Wenn ein Commit nicht kompiliert oder die Testinfrastruktur an diesem Punkt kaputt ist – überspringt bisect diesen Commit und wechselt zum nächsten Kandidaten.

Wenn Bisect git blame übertrifft

git blame sagt Ihnen, wer die letzte Zeile verändert hat. Nützlich, wenn Sie bereits wissen, welche Zeile falsch ist. git bisect ist dafür gedacht, wenn Sie es nicht wissen – wenn das Symptom verhaltensbezogen ist und die Ursache überall sein könnte.

Verwenden Sie bisect, wenn:

• Sie das Regressionsverhalten reproduzieren können, aber nicht auf eine bestimmte Datei zurückverfolgen können
• Das Verhalten in der Produktion hat sich geändert, aber es gibt keine offensichtliche Vermutung in der jüngeren Geschichte
• „Das funktionierte in v2.3, bricht in v2.5“ mit 80+ Commits dazwischen
• Ein Test begann konsistent um einen bestimmten Zeitpunkt zu scheitern

Wenn beim Vergleich der Ausgabe zwischen zwei Commits während des bisects beide in ein Text-Diff-Tool eingefügt werden ist oft schneller als die Lesung von unified Diffs im Terminal – besonders wenn die Ausgabe ein Blob von JSON oder ein serialisierter Objekt ist.

Trampas comunes

Vergessen Sie nicht git bisect reset. Bisect checkt Commits in einem detached HEAD Zustand aus. Wenn Sie während der Sitzung einen Branch wechseln, ohne ihn zurückzusetzen, wird der bisect-Zustand veraltet und Sie werden verwirrt. Setzen Sie immer zurück, selbst nachdem Sie die Antwort gefunden haben.

Merge Commits können den Bereich verzerren. Wenn Ihr Bereich eine lange lebende Feature-Branch enthält, die eingefügt wurde, könnte bisect sich in einem nicht offensichtlichen Reihenfolge in diesen Branch-Commits befinden. Führen Sie git log --oneline --no-merges good..bad erst aus, um zu verstehen, was im Bereich enthalten ist.

Testreproduzierbarkeit ist alles. Wenn Ihr Check instabil ist – zeitabhängig, umgebungsabhängig oder greift auf einen externen Dienst – wird bisect Ihnen schlechte Ergebnisse liefern. Stellen Sie sicher, dass der Test deterministisch ist, bevor Sie ihn automatisieren.

Der Commit, den bisect identifiziert, ist der Punkt, an dem das Verhalten sich geändert hat, nicht unbedingt der Ort, an dem das Bug liegt. Manchmal hat ein korrekter Refaktor eine vorbestehende Annahme anderswo enthüllt. Behandeln Sie das Ergebnis als „beginnen Sie hier zu lesen“, nicht als „revertieren Sie diesen und Sie sind fertig“.

Wenn Sie git-Verlauf regelmäßig debuggen, ist die Git-Spickzettel auf IO Tools mit bisect, blame, log Flags und reflog auf einer Seite – wertvoll zu bookmarken, wenn etwas mysteriös bricht.

Das könnte Ihnen auch gefallen