Schneller Fehler in eurer Webseite finden mit Git

Kennt ihr das? Ihr baut ein neues Feature in eure TYPO3 Webseite, ändert hier was, fügt dort etwas hinzu, schaut euch hinterher alles an und alles sieht gut aus. Fein denkt ihr. Kann ich einchecken und weiter machen. Ein wenig Zeit vergeht, die Seite entwickelt sich weiter, ihr fixt Bugs, weitere Features kommen und alles ist prima.

Dann aber plötzlich und unerwartet stellt ihr einen Fehler in einem anderem Bereich eurer Webseite fest. Eigentlich wart ihr da gar nicht dran und alles müsste funktionieren. Irgendwo muss sich doch tatsächlich ein Fehler eingeschlichen haben. Aber wann und wo? Um das herauszufinden müsst ihr jetzt eigentlich alle eure Commits manuell durchgehen bis ihr den Verursacher findet. Oh man, das kann dauern.

Glücklicherweise habt ihr euch mal entschieden euer Projekt zu "vergitten". Eine gute Entscheidung, denn jetzt könnt ihr ein super Feature von Git nutzen, welches euch genau diese Arbeit sehr vereinfacht.

Git Bisesct

Kurz gesagt, git bisect übernimmt für euch die Auswahl der Commits, die geprüft werden müssen um den Commit zu finden, bei dem der Fehler das erstemal auftritt.

Ihr müsst Git an den entsprechend Stellen nur sagen, ob der Fehler gerade auftritt oder nicht. git bisect kann also nicht beurteilen ob euer Code richtig oder falsch ist. Es entscheidet anhand eurer Angaben welches der nächste Commit zum Testen ist.

Aber genug der ganzen Erklärung. Wie so oft ist es manchmal besser die Dinge einfach zu tun um daraus zu lernen.

Wir nehmen einmal an, ihr habt einen Branch "main" in euerem Git und ihr seid ganz vorn auf dem Branch. Von einem eventuell vorhandenen Remote habt ihr gepullt und ihr seid quasi auf dem letzten Stand. 

Hier entdeckt ihr jetzt, dass auf eurer TYPO3 Webseite etwas kaputt ist. Zum Beispiell die Ansicht einer einzelnen News hat irgendein Problem mit den Templates. Auf alle Fälle sollte es ein Problem mit dem Code geben. Fehler die aufgrund von Änderungen in der Datanbank auftauchen können so natürlich nicht entdeckt werden.

Ihr müsst nun als erstes einen Stand in eurem Projekt finden bei dem der Fehler noch nicht auftrat. Git braucht eine Information wo es anfangen soll. Dazu geht ihr so weit in der Historie zurück wie ihr es eben für richtig haltet. Das kann 1 Woche sein oder auch ein 1 Jahr. Checkt diesen Stand aus und prüft ob da mit der Newsansicht wirklich noch alles in Ordnung war.

Wenn ja, dann kopiert euch am besten den Commithash. Den braucht ihr später noch. Wenn nein, dann geht noch weiter zurück. Solange bis ihr einen Stand gefunden habt der funktioniert.

Danach geht ihr wieder zurück auf die Spitze vom main Branch. Das ist ja der aktuelle Stand wo ihr den Fehler entdeckt habt. 

Nachdem die Vorbereitungen abgeschlossen sind, können wir mit der eigentlichen Suche nach dem fehlerhaften Commit beginnen.

Als erstes startet ihr den Vorgang mit

git bisect start

Im Terminal seht ihr jetzt noch nichts besonderes aber ein kurzes git status zeigt euch, dass etwas passiert ist.

HEAD losgelöst bei x.x.x
Sie sind gerade bei einer binären Suche, gestartet von Branch 'xxxxxxxx'.

(benutzen Sie "git bisect reset", um zum ursprünglichen Branch zurückzukehren
nichts zu committen, Arbeitsverzeichnis unverändert

Die x'e in dem Beispiel sind dabei eure Tags (so ihr den welche gesetzt habt) bzw. ein Commithash. 

Als nächstes sagen wir git, dass der aktuelle Commit nicht funktioniert, also schlecht ist.

git bisect bad

Auch jetzt passiert noch nicht viel. Wann passiert denn da endlich mal was? 

Genau jetzt. Wir sagen Git jetzt welcher Commit derjenige ist, bei dem noch alles in Ordnung war. Dazu habt ihr euch vorhin hoffentlich den Commithash kopiert. Der wird jetzt benutzt.

git bisect good xxxxxxxxxxxxxxxxxxxxxxxx

Die x'e ersetzt ihr jetzt mit dem vorhin kopierten Commithash. Und nach abfeuern des Befehls sollte ihr eine Meldung ähnlich wie diese hier bekommen:

Binäre Suche: danach noch 6 Commits zum Testen übrig (ungefähr 3 Schritte)
[293gd673h548eh3894hre93h3r594] [TASK] Your best commit message ever

Git hat jetzt den Commit ausgecheckt, der mittig in der Historie zwischen dem schlechten (kaputten) und dem letzten funktionierenden liegt.

Ihr müsst jetzt testen ob der Fehler auf eurer Seite noch existiert oder nicht.

Wenn der Fehler nicht auftritt ist sagt ihr das git mit dem Befehl git bisect good. Wenn der Fehler hier weiterhin auftritt nutzt ihr das Kommando git bisect bad.

Dadurch kann git entschieden welches der nächste Commit zum Testen ist. Entweder in Richtung des letzten "schlechten" Commit oder in Richtung des letzten "guten" Commit.

Dadurch wird die Anzahl der Commits, die sich zwischen einem kaputten und einem funktionierenden Commit befinden, immer kleiner. Ihr müsst also nach jedem git bisect Kommando immer wieder prüfen ob der Fehler da ist oder nicht. Und dabei git immer wieder sagen good oder bad.

Am Ende bleibt genau der Commit über, welcher den Fehler verursacht hat. Git zeigt euch dabei dann genaue Infos zu diesem Commit. Das könnte in etwas so aussehen:

83js93h3494hj30383j393uj39393 is the first bad commit
commit 83js93h3494hj30383j393uj39393
Author: Karsten Nowak <nowak@undkonsorten.com>
Date:   Tue Dec 12 19:31:14 2023 +0100

    [TASK] Add missing viewhelpers and others
    
    Many different changes changes.
    This is my very best commit message.
    TYPO3 is a great CMS :-)
    
    Related: #666

 Classes/ViewHelpers/FileExistsViewHelper.php       | 32 +++++++++
 Classes/ViewHelpers/InArrayViewHelper.php          | 76 ++++++++++++++++++++++
 .../Private/News/Partials/Category/Items.html      |  4 +-
 .../Private/Page/Partials/OffCanvas/OffCanvas.html |  1 -
 Resources/Private/Page/Partials/PageHeader.html    |  4 +-
 composer.json                                      |  5 ++
 6 files changed, 117 insertions(+), 5 deletions(-)
 create mode 100644 Classes/ViewHelpers/FileExistsViewHelper.php
 create mode 100644 Classes/ViewHelpers/InArrayViewHelper.php

That's it. Das ist der fehlerhafte Commit. Hier seht ihr jetzt genau was, wann und wo geändert wurde. Jetzt müsst ihr einmal das git bisect beenden. Das könnt ihr mit diesem Befehl:

git bisect reset

Damit seid ihr wieder auf dem ursprünglichen Commit vom Anfang wo ihr gestartet seid. Ihr könnt euch jetzt ans eigentliche Fixen des Fehlers setzen. Dank Git kennt ihr jetzt ja genau die Stelle wo ihr ansetzen müsst.

In diesem Sinne, frohes Fehler fixen und ein gemütliches Weihnachtsfest ohne Bugs.

Wer es jetzt noch genauer wissen will, kann in der Git Dokumentation alles noch einmal genau nachlesen.