Wie man git nicht benutzen sollte


Wer sich der agilen Softwareentwicklung verpflichtet fühlt und jederzeit ein fertiges Produkt ausliefern möchte, dass kontinuirlich verbessert wird kommt am Versionsverwaltungssystem git nicht vorbei. Es hat inzwischen ältere Tools wie Subversion oder CVS verdrängt und Webseiten wie github sind längst zum Quasi-Standard avanciert. Nicht nur dass git das verteilte Arbeiten unterstützt sondern es ist auch unschlagbar effizient programmiert. Auch von größeren Projekten kann man ohne Zeitverzögerung einen Branch erstellen.

Bei soviel Erfolg gibt es natürlich auch Gegenstimmen. Diese können sich mit Versionsverwaltungen nicht anfreunden und stehen agilen Entwicklungsmethoden kritisch gegenüber. Eine Entscheidung gegen git wird ganz bewusst getroffen um sich nicht mit merging und staging beschäftigen zu müssen und man so mehr Zeit hat sich um den eigentlichen Code zu kümmern. Es gibt aber auch einen Mittelweg und der soll im folgenden vorgestellt werden.

Nehmen wir mal an, man nutzt git gezwungenermaßen möchte aber seine Arbeitsweise nicht umstellen. Die übliche Arbeitsweise ohne git sieht so aus, dass man ein Arbeitsverzeichnis erstellt, dort dann Dateien ablegt und wenn man eine neue Version hat, dafür dann eine neue Datei erstellt. Ein Namensschema könnte so lauten:
– version0-1.py
– version0-2.py
– version1-0.py

Die landläufige Annahmen lautet, dass mit git alles anders ist und man dort stattdessen in einem Master-Branch arbeitet wo Änderungen transparent geloggt werden. So steht es vielleicht im Lehrbuch man kann git aber auch gänzlich anders einsetzen. Und zwar erstellt man sich als erstes ein neues Repository und legt dort ein Verzeichnis an. In diesen Verzeichnis schreibt man dann die selben Dateien hinein, die man auch als nicht-git-Anwender nutzen würde. Erstellt also für jede neue Version eine neue Datei. Man nutzt den Master Branch so, als wäre es ein ext4-Dateisystem nur mit dem Unterschied dass man ein Logfile hat. Die jeweils aktuelle Version ist dann die Datei mit der höchsten Versionsnummer.

Und anstatt Branches zu erzeugen wenn man neue Features implementieren will, legt man stattdessen im Master-Branch ein Unterverzeichnis an was gerne auch old/ oder temp/ heißen darf und schreibt dort dann seinen Code hinein.

Natürlich ist diese Arbeitsweise nicht förderlich wenn es um gute Softwareentwicklung geht. Denn die git-internen Mechanismen welche funktionsfähigen Sourcecode sicherstellen sollen wie Branching, Merging, Diff oder logging werden unnötig. Wenn man für jede neue Version eine neue Datei erstellt kann git dazu keinen Tree erstellen, sieht also nicht, dass die Versionen aufeinander aufbauen. Ebenfalls macht es keinen Sinn Code zusammenzufügen (merging), sondern stattdessen kopiert man im Git-Dateisystem einfach die letzte Version aus dem developer-Verzeichnis in das Hauptverzeichnis.

Normalerweise erfolgt die Interaktion mit git entweder über die Kommandozeile oder mit Hilfe von Frontends wie egit. Auf diese Weise werden Änderungen in den Dateien ermöglicht, Rollbacks ausgeführt oder Dateien zusammengeführt. Auch findet über GUI Tools eine Einsicht in die Historie statt, um herauszufinden wie der frühere Stand war. Wenn man hingegen git nutzt, um Verzeichnisse und Dateien anzulegen und lediglich einen push durchführt um diese Änderungen auf den Server zu schicken verwendet man git wie einen FTP-Server. Diese Arbeitsweise ist zwar nicht explizit falsch, weil es keine Fehlermeldungen gibt, aber sie entspricht auch nicht dem, was in den git-Anleitungen empfohlen wird. Es ist eine Arbeitsweise die am alten Dateisystem-Denken festhält und git lediglich als Notizbuch nutzt. Als eine Art von verbessertem ZFS Filesystem wo man für jede Version eine neue Datei anlegt.

Um das Anti-Pattern für git ein wenig zu vertiefen. Zuerst clont man ein git-Repository und erzeugt darin dann ganz normal ein Verzeichnis: „mkdir folder“. Jetzt nimmt man dieses Verzeichnis in die git Historie auf: „git add folder/“. Und damit steht das Verzeichnis sozusagen unter Beobachtung. Wenn man jetzt darin irgendwelche Dateien hineinschreibt und einen commit ausführt wird die Änderung protokolliert. Erstaunlicherweise wird diese Methode zwar bei stackoverflow und andere Webseiten erwähnt aber nicht an prominenter Stelle. Der Grund ist vermutlich dass über Folder und Dateien der Anwender ein Konzept an die Hand bekommt, was in git eigentlich durch etwas besseres ersetzt werden sollte (die Versionsverwaltung). Sobald man anfängt mit Unterverzeichnissen zu arbeiten benutzt man git nur als Storage und ist damit unabhängig von irgendwelchen git logs. Denn entweder ist im eigenen Untererzeichnis die Datei noch drin oder sie fehlt eben. Und wenn man eine Kopie von einer Datei erstellen möchte, nutzt man einfach den Linux Befehl „cp file1.py file2.py“. Anschließend kann man in dieser Datei Änderungen vornehmen.

Diese Empfehlung weicht davon ab, wie normalerweise die Arbeitsweise mit git erfolgt. Die Best-Practive Methode wäre gewesen, dass man einen Branch erstellt, diesen auscheckt und die Datei „file1.py“ in einem Texteditor öffnet um Änderungen durchzuführen. Wenn man das jetzt commitet und pusht kann man in der Historie die Änderung nachvollziehen.

Wenn man hingegen wie oben empfohlen, zunächst eine Kopie der Datei erstellt um dort dann die Änderung durchzuführen wird zwar auch das im git logfile erscheinen allerdings dürfte für einen Außenstehenden deutlich werden, dass der Anwender das Konzept von git offenbar nicht verstanden hat. Er hat nicht verstanden, dass man Dateien nicht zu kopieren braucht aber dennoch auf die alte Version zugreifen kann. Aus Sicht des Anwenders sieht es etwas anders aus. Um normalerweise an die alten Dateien zu gelangen müsste man die git Befehle kennen. Man müsste erst mittels „git log“ herausfinden welchen Hash-Wert eine Änderung hat, um dann mit einem zweiten Befehl diese konkrete Version zu extrahieren. Das ist technisch möglich, aber aufwendig. Wenn man hingegen alle alten Dateien schön übersichtlich im Folder ablegt kann man ganz normal darauf zugreifen.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s