Fehlersuche mit „git bisect“

In größeren Projekten arbeiten meist mehrere Entwickler an einem Git-Repository. Und wie es bei der Software-Entwicklung nun einmal ist kommt es ab und an zu Fehlern. Bei einer komplexen Versionshistorie ist es allerdings schwierig den Ursprungscommit eines Fehlers zu finden. An dieser Stelle hilft das Git-Kommando bisect weiter. Zum Start muss Git mitgeteilt werden welcher der letzte (aus Sicht des Entwicklers) korrekt funktionierende und der erste fehlerhafte Commit ist. Dies geschieht im Terminal auf dem Repository mittels:

git bisect start
git bisect good <hash>
git bisect bad <hash>

Danach checkt bisect einen Commit aus. Dieser Commit muss nun auf den gesuchten Fehler überprüft werden. Ist der Fehler weiterhin vorhanden, so teilen wir dies Git mittels:

git bisect bad

mit. Ist der Fehler nicht mehr vorhanden, so teilen wir Git dies ebenfalls mit:

git bisect good

Dieser Prozess wird dabei so lange durchlaufen bis Git uns am Ende des Prozesses mitteilt, in welchem Commit der Fehler seinen Ursprung hat. Danach können wir uns den Commit notieren und bisect mittels:

git bisect reset

mitteilen das der Prozess zu einem Ergebnis geführt hat. Dadurch wird das Repository in seinen Ursprungszustand versetzt.

Git-Visualisierung mit SeeGit

Ein Git-Repository kann aus vielen Branches bestehen welche ab und an mit dem Hauptentwicklungszweig gemergt werden. Dies führt dazu das man die Geschichte eines solchen Repositories in Form eines Graphen darstellen kann. Ein Tool um sich sein Repository in Form eines Graphen anzeigen zu lassen ist dabei SeeGit.

SeeGit mit einem geöffneten Repository

SeeGit mit einem geöffneten Repository

Problematisch wird die Bedienung von SeeGit bei größeren Repositories. Dort nimmt der Ladevorgang sehr lange in Anspruch, während der Graph aufgebaut wird. Lizenziert ist SeeGit unter der MIT-Lizenz und damit freie Software – der Quelltext ist auf GitHub zu finden. SeeGit läuft auf Grund einiger Abhängigkeiten zur Windows-API leider nur unter Windows.

Gitgraph.js

Spätestens mit verteilten Systemen wie Git, ist bei vielen der Erklärungsbedarf gestiegen. So werden in Firmen Richtlinien definiert, wie nun gebrancht und gemergt werden darf. Da eine grafische Visualisierung solcher Prozesse wesentlich eingängiger ist, gibt es Frameworks und Bibliotheken wie Gitgraph.js. Dabei handelt es sich um eine JavaScript-Bibliothek um solche Graphen schnell und einfach zu erzeugen und diese auf Webseiten einzubinden.

gitgraphjs.com

gitgraphjs.com

Lizenziert ist der Quelltext unter der MIT-Lizenz und damit freie Software. Der Quelltext kann über GitHub bezogen werden. Die offizielle Seite des Projektes ist unter gitgraphjs.com zu finden.

GitUp – freier Git-Client für Mac OS X

Für Mac OS X gibt es einige freie Git-Clients. Das Problem an den meisten dieser Clients ist das sie nicht mehr weiterentwickelt werden. Ein ziemlich aktueller und aktiv weiterentwickelter Client ist GitUp. Der Client beherscht dabei die nötige Grundfunktionalität, kann aber auch mit Spezialitäten wie Submodulen umgehen. Besonders hervorzuheben ist Map-Ansicht, in welcher man durch den Graph der Commits und Branches navigieren kann.

GitUp in der Map-Ansicht

GitUp in der Map-Ansicht

Lizenziert ist GitUp unter der GPL3 und damit freie Software – der Quelltext ist auf GitHub zu finden. Bezogen werden kann GitUp über die offizielle Projektseite unter gitup.co.

Submodule unter Git nutzen

Manchmal möchte man Git-Repository in einer bestimmten Art strukturieren. So will man unter Umständen mehrere Repositories logisch zu einem Repository gesellen. Dafür gibt es unter Git Submodule. Gegeben sei folgende Repositorystruktur:

Framework
Library1
Library2
Library3

Möchte man die Bibliotheken Library1, Library2 und Library3 logisch in das Repository Framework einbinden, kann man die Submodule nutzen. Dazu geht man in das Repository Framework und fügt die andere Repositories als Submodule hinzu:

git submodule add :Library1
git submodule add :Library2
git submodule add :Library3

Damit wird im Repository Framework eine Datei mit dem Namen .gitmodules angelegt, in welcher folgender Inhalt zu finden ist:

[submodule "Library1"]
	path = Library1
	url = :Library1

[submodule "Library2"]
	path = Library2
	url = :Library2

[submodule "Library3"]
	path = Library3
	url = :Library3

Diese Datei kann dann per Commit dem Repository hinzugefügt werden. Beim klonen eines solchen Repositories, muss man nur darauf achten das es rekursiv geklont und gepullt (git submodule foreach git pull) wird, damit die Submodule ebenfalls aktualisiert werden.