Warum ich Git nicht mag: Versteckte Integrität

Ursprünglicher Autor: Armin Ronacher
  • Übersetzung


Ich mache Sie auf die Übersetzung eines kurzen Artikels aus dem Blog von Armin Ronacher aufmerksam - Autor von Flask, Jinja2 und vielem mehr. Dieses Mal wird er seine Gedanken über Git teilen - ein verteiltes Versionskontrollsystem für Dateien.

Git ist ein interessantes Thema für mich. Ich habe zuerst versucht, Git zu verwenden, als es überhaupt kein Befehlssystem gab, und Cogitowurde als vielversprechendes Projekt angesehen. Ich kann nicht sagen, dass es mir gefallen hat, damals habe ich hauptsächlich SVN verwendet und es hat alle meine Probleme vollständig gelöst. Bald traf ich Mercurial, und es war die Liebe auf den ersten Blick, die den Grundstein für eine lange und positive Erfahrung mit diesem VCS (Versionskontrollsystem) legte, das einen treuen Unterstützer in meinem Gesicht hatte. Erst 2008 wechselte ich zu Git, und es dauerte mehrere Versuche, bis mir klar wurde, dass es Zeit war, meine Repositorys darauf zu migrieren.

Monströses Git-Befehlssystem


Ich vermute, dass ein Entwickler, der von einem anderen Versionskontrollsystem zu Git gewechselt ist, unangenehm über die mangelnde Integrität seiner Teams überrascht sein wird. Steve Losh war nicht zu faul, um dies in seinem „ Git Koans “ zu schlagen .

Jedes Mal, wenn dieses Thema erneut besprochen wird, bin ich etwas verwirrt, da ich mich an keine Probleme mit den Git-Befehlen in meiner täglichen Arbeit erinnern kann. Natürlich unterscheidet sich die Syntax von "git remove" von "git branch" und "git tag" - aber ich verwende sie für verschiedene Aufgaben, ohne an Inkonsistenzen zu denken. Der einzige seltsame Befehl, an den ich mich erinnere, ist git show: Die Syntax zum Anzeigen des Inhalts eines Objekts ist jedes Mal rätselhaft.

Aber was Mercurial und Perforce betrifft, kann ich mich leicht an den häufigen Kampf bei der Durchführung gewöhnlicher Routineoperationen erinnern - was man über Git nicht sagen kann. Warum macht mir das Git-Befehlssystem nicht so viel Abneigung?

Lernteams vs. Lernideen


Als ich über diese Frage nachdachte, kam ich zu dem Schluss, dass der Grund für eine so einfache Übernahme der Git-Syntax die Prinzipien ihrer Untersuchung durch Programmierer sind. Im Fall von Mercurial und Perforce beherrscht der Entwickler eine Reihe von Befehlszeilen-Zaubersprüchen zum Lösen bestimmter Aufgaben, und alles, was sich „unter der Haube“ befindet, wird weggelassen.

Und für Git ist das Gegenteil der Fall: Auf den ersten Seiten der Einführung wird der Leser auf die Beschreibung der Interna dieses VCS verwiesen , in der detailliert beschrieben wird, was und wie es funktioniert.

Diese Trainingsmethode geht auf die Zeit zurück, als Git überhaupt kein Befehlssystem hatte. Es wurde erwartet, dass der Entwickler die Dateien im Verzeichnis ".git" manuell bearbeitet! Ich erinnere mich an meine ersten Experimente mit diesem System, als der Commit-Befehl nicht einmal existierte:.git/HEAD, aber nur ein Symlink zum aktuellen Zweig, und die dokumentierte Art des Festschreibens war:

echo "Commit message" | git-commit-tree $(git-write-tree) > .git/HEAD

Erst nach einer Weile wurde dem Befehl die Operation "Festschreiben" zugewiesen, aber selbst dann war die Anweisung für seine Verwendung ... so .

Git wurde ursprünglich nicht als VCS entwickelt: Es wurde als Idee erstellt, die andere Programme zum Erstellen von VCS verwenden können. Und das unterscheidet den Git-Entwicklungsprozess grundlegend von der Entwicklung aller anderen Versionskontrollsysteme.

Natürlich hat sich Git in den letzten 10 Jahren stark verändert, und einige der Ideen in seiner Basis haben sich geändert, aber das Wesentliche hat sich nicht wesentlich geändert. Das Erstellen eines Repositorys mit Git 2005, das Festschreiben mit derselben Version und das Anzeigen des Protokolls mit Git 2015 sind von einiger Schönheit.

Um mit Git arbeiten zu können, müssen Sie natürlich nicht das einfachste Befehlssystem lernen, aber die grundlegenden Ideen, die diesem VCS zugrunde liegen, sind es wert.

Gutes Standardverhalten


Das Git-Befehlssystem ist zwar nicht das bestmögliche, aber sie sind mit einem guten Standardverhalten ausgestattet, das sich nur jedes Jahr verbessert. Das Verhalten von Git "out of the box" ist angemessen, die beliebtesten Arbeitsmethoden entsprechen den Einstellungen der Teams, und wenn dies nicht der Fall ist, können Sie sich auf eine offene Diskussion verlassen. Für die meisten Aufgaben gibt es eine „genehmigte“ Möglichkeit, sie mit Git auszuführen, und diese Methode ist normalerweise leicht zu erlernen. Die Arbeit mit Zweigen in Git hat sich seit ihrer Gründung nicht geändert, und das vor 10 Jahren gewonnene Wissen ist immer noch relevant.

Gute Architektur


Ich glaube, dass Linus, als er Git schuf, eine verdammt gute Architektur für ihn entwickelt hat, die in Zukunft nur minimale Änderungen erfordert. Wie die Zeit gezeigt hat, wurde die Arbeit mit Commits und Objekten sowie der Mechanismus für die Arbeit mit Zweigen korrekt implementiert. Sogar Mercurial hat aufgegeben und warnt den Benutzer jetzt, dass das Erstellen eines benannten Zweigs keine gute Idee ist.

Nachdem ich die grundlegenden Konzepte von Git studiert habe, kann ich die gesamte Breite seiner Tools sicher nutzen. Natürlich muss man manchmal in Google einsteigen, um einige seltene Teams aufzufrischen, aber ein solches Bedürfnis entsteht im Arbeitsalltag kaum. Ich hatte noch nie die Gelegenheit, das Repository zu beschädigen, und konnte nicht alles reparieren.

Dem Git-Befehlssystem mangelt es an Integrität und Einfachheit, aber seine Architektur weist beide Eigenschaften auf, und ich schätze Git dafür.

Git an meiner Seite


Einer der Gründe, warum ich Git für sein Befehlssystem und an einigen Stellen unangenehmes Verhalten vergebe: Er spielt immer an meiner Seite. Oft habe ich das Repository auf monströse Weise zerstört, falsche Zusammenführungen vorgenommen und die falschen Daten gelöscht, aber es gab nie einen Fall, in dem die Daten verloren gingen oder VCS mich mit den Ruinen allein ließ.

Bei Problemen erstelle ich manchmal eine Kopie meines ".git" -Verzeichnisses und überprüfe dann im Nachhinein, was ich falsch gemacht habe. Situationen, in denen eine Wiederherstellung nicht möglich ist, sind äußerst selten - und dies ist eine der Optionen, bei denen Git sein Potenzial voll ausschöpft. Ich erinnere mich noch an meine Fehler mit anderen Versionskontrollsystemen, die das Repository in die Luft sprengten und es unmöglich machten, es ohne die Beteiligung der Entwickler dieses VCS wiederherzustellen.

In meinem Gedächtnis gab es keinen einzigen Fall eines kaputten Repositorys aufgrund einer unsachgemäßen Verwendung von Git oder seiner internen Arbeit, während ich bei anderen VCS die traurige Erfahrung habe, dass kaputte Arbeitskopien von Subversion, zerstörte Server, kaputte Perforce-Arbeitsbereiche und beschädigte Mercurial-Repositorys beschädigt wurden mit meinen Händen.

Das Schlimmste, was mir mit Git passiert ist, waren die falschen Berechtigungen für eine Reihe von Dateien im Flask-Repository, die aufgrund eines GitHub-Fehlers entstanden sind.

Fazit


Ich denke, ich würde es nicht ablehnen, mehr Software wie Git zu haben. Software, bei der die interne Arbeitslogik ein wichtiger Bestandteil der Interaktion mit dem Benutzer ist und die Benutzeroberfläche nicht von der Black-Box-Implementierung getrennt ist.

Ein Gegenbeispiel für solche Software ist die kognitive Trennung, die zwischen mir und den neuesten Apple-Softwarelösungen entsteht. Es gibt kein Fenster "Speichern unter" mehr, und im Dialogfeld "Speichern" wird jetzt häufig eine Schaltfläche zum Löschen angezeigt, auch wenn nichts im Dateisystem gespeichert wurde. Zu oft habe ich Präsentationen in Keynote neu geschrieben, weil sich die Logik des Dateisystems und die Logik der Benutzeroberfläche grundlegend unterscheiden. Es ärgert mich, wenn grundlegend unterschiedliche Vorgänge (noch nicht gespeicherte Daten verwerfen und eine bereits im Dateisystem gespeicherte Datei löschen) benannt werden und gleich aussehen.

Vom Übersetzer


Sie können diesen Freitag, den 20. März, im Rahmen der PiterPy- Konferenz , zu der wir sie eingeladen haben, mit dem Autor des Artikels und anderen namhaften Pythonisten in St. Petersburg chatten :) Auf der Veranstaltung, die Positive Technologies als Hauptsponsor unterstützt, werden auch Experten des Unternehmens Alexander sprechen Koshkin und Ivan Tsyganov sowie sein Hauptentwickler Sergey Matveenko werden der Anführer eines der Streams.

Übersetzung: Grigory Petrov (@eyeofhell)

Jetzt auch beliebt: