Auch wenn es einige gewichtige Argumente gegen Git gibt: Bei der Lektüre von Scott Chacons Buch Pro Git (gedruckte Version) wird mir das ganze Potential der postklassischen Versionskontrollsysteme klar: Auch wenn mir das Offline-Branching bislang immer am wichtigsten war (auf diese Weise kann ich im Zug einfach einen experimentellen Branch erstellen), bietet die Idee, stets das Repository bei sich zu führen (von Server-Hooks abgesehen), doch erheblich mehr Vorteile.
Zudem gefällt mir besonders gut, dass man Versionen einer Datei auch dann wiederherstellen kann, wenn der Branch (sollte eigentlich “das Branch” heißen, aber dagegen sträubt sich mein Sprachempfinden) gelöscht wurde. Das ist in Subversion z.B. nicht möglich. Ebenso ist das Konzept des “Staging” (geänderte Dateien werden erst nach einem expliziten Stage-Befehl committed [kann man auch deaktivieren]) für mich sehr nützlich – in Subversion habe ich bislang (vor allem graphisch) andersherum gerade in größeren Projekten gearbeitet: Aus der Fülle der geänderten Dateien musste ich immer die “herauspicken”, die nicht committet werden sollten, was sehr zeitraubend war. Jetzt geht es andersherum: Nur die Dateien, die wirklich wieder ins gemeinsame Repository sollen, gehen nach “Staging”, alle anderen bleiben erst einmal lokal.
Nun beleuchtet Zack Voase in seiner Gegenüberstellung des Quellcodes Gits und Mercurials, dass für eine vergleichbare Funktionalität ein Quellcodeverhältnis von 10 (Git) zu 1 (Mercurlal) vorhanden ist.
Da frage ich mich natürlich, wann endlich der Git-Nachfolger programmiert wird. Und zwar in Scala 🙂
Schreibe einen Kommentar