Erfahrungsbericht: erste Schritte mit Git, Ruby on Rails und MongoDB (Teil 2)

Willkommen zum zweiten Teil der Miniserie „erste Schritte mit Git, Ruby on Rails und MongoDB“. Im ersten Teil habe ich beschrieben, wie es zu diesem Experiment gekommen ist und warum ich mich für einen Issue-Tracker als Beispielanwendung entschieden haben. Heute schildere ich meine Erfahrungen mit dem ersten neuen Teammitglied Git.

Git statt SVN

Ich gehe auf einige Punkte ein, die ich erwähnenswert finde bzw. die unseren Workflow in der Agentur tangieren. Seht euch für umfassende Vergleiche bitte im Web um, das können andere wesentlich besser und vollständiger beschreiben als ich. 😉

Glossar

Zur Auffrischung bzw. als Orientierung:

• Repository: Versionierungssysteme wie Git oder SVN verwalten eure Dateien in Repositories. Die zu versionierenden Dateien werden hierzu ganz normal im Repository-Verzeichnis abgelegt. Zusätzlich gibt es aber spezielle Verzeichnisse (.svn bzw. .git), die Meta-Informationen zu den vergangen Versionen der Dateien, Entwicklungszweigen, dem Zustand des Repositories, Einstellungen usw. enthalten.
• Checkout: Das Repository kümmert sich also um die gesamte Entstehungsgeschichte der Dateien. Wenn man die Dateien bearbeiten möchte, holt man sich eine Kopie der Dateien. Das holen bezeichnet man als Checkout.
• Working Copy: Wenn man ein Checkout macht, erhält man eine (Arbeits)kopie der Dateien. Auf Englisch Working Copy.
• Commit: hat man seine Änderungen vollzogen, möchte man sie versionieren. Dazu muss man sie ans Repository schicken. Das ist der Commit.
• Branch: ein Branch ist ein Entwicklungszweig. Für die Betreuung einer Website ist es sinnvoll, bei größeren Anpassungen einen eigenen Entwicklungszweig zu erstellen, um dort ungestört an den Neuerungen basteln zu können.
  Ein Beispiel: es werden häufig Kleinigkeiten auf der Site geändert (z.B. in der Darstellung). Zugleich soll ein Update auf eine neue Softwareversion erfolgen oder ein neuer Websitebereich eingeführt werden, der auf zahlreiche bestehende Seiten Auswirkungen hat und dessen Entwicklung mehrere Tage oder Wochen benötigt. Da mit den kleinen Änderungen nicht gewartet werden, bis das Update oder der neue Bereich fertig implementiert und getestet sind, erstellt man für das Update / den Websitebereich einen eigenen Branch und arbeitet die Kleinigkeiten im Hauptentwicklungszweig (als „trunk“ bezeichnet) ein. Das ist auch nützlich, um immer einen stabilen Zweig zu haben, in dem man kurzfristig auf schwerwiegende Probleme reagieren kann. Ist alles fertig, werden die Branches wieder zu einer Code-Basis zusammengeführt.
• Merge: bei einem Merge werden zwei (oder mehr) Branches zusammengeführt.

To commit or not to commit

Kurz gesagt: die Umstellung von Git zu SVN ist nicht groß. Besonders wenn es um das Tagesgeschäft geht (Dateien entfernen und hinzufügen, Änderungen übernehmen), bleibt eigentlich alles beim alten. Der größte Unterschied ist, dass Git eine so genannte Stage vorsieht. Wenn man unter Subversion eine Datei bearbeitet und ein Commit ausführt, werden die Änderungen an der Datei automatisch in das Repository aufgenommen. Bei Git muss man die Änderung jedoch erst in die Stage aufnehmen, damit sie im Repository landet.

Im ersten Moment erscheint das vielleicht mühsam. In der Praxis ist es aber sehr sinnvoll. Falls man an mehreren Kleinigkeiten parallel arbeitet und dann doch nur einen Teil commiten will (sollte theoretisch nicht vorkommen, aber die Kunden machen es manchmal erforderlich ;)), muss man in Subversion nämlich vorsichtig die Dateien herauspicken, die man commiten will.

In Git aber kann man Dateien nach Belieben in die Stage aufnehmen (also für die Berücksichtigung beim Commit kennzeichnen) – die Modifikationen, die nicht gestaged wurden, bleiben natürlich im Arbeitsverzeichnis und warten darauf, dass man sie später in die Stage verfrachtet. Übrigens kann man sogar nur bestimmte Zeilen einer Datei stagen, falls das nötig ist.

Damit man den Überblick behält, liefert der Befehl „git status“ zwei Listen: die erste Liste verrät, welche Dateien man lediglich in der Working Copy bearbeitet hat und die zweite Liste zeigt, welche Dateien bereits in die Stage aufgenommen sind und somit beim nächsten Commit übermittelt werden. Wem das alles jedoch zu mühsam ist, der fügt beim commit den Parameter -a hinzu und versioniert so alles, was geändert wurde. Soll auch ganz gut funktionieren. 😉

Zentrale vs. dezentrale Repositories

Jetzt habe ich aber mittendrin angefangen, daher noch einmal zum Beginn. SVN verwendet bekannterweise ein zentrales Repository. Jeder Entwickler macht einen Checkout und hat somit eine Working Copy in seiner Entwicklungsumgebung. Der Developer nimmt Anpassungen vor und spielt die Dateien mittels Commit in das zentrale Repository zurück.

Git verfolgt ein anderes Prinzip: alle Entwickler haben vollständige, gleichberechtigte Repositories. Es gibt kein Repository, das per se DAS Repository ist und den anderen vorsteht. Man spricht hier von dezentralen oder verteilten Repositories. Jeder Entwickler betreibt sein Repository (und hat darin seine Working Copy). Änderungen werden im lokalen Repository verwaltet und über Push-/Pullrequests an Kollegen herangetragen.

Häufig möchte man aber in der Praxis eine zentrale Anlaufstelle haben. Das ist auch in Git möglich, indem man ein Bare Repository einrichtet. Dieses ist – wie das Repository bei SVN – nicht zum Entwickeln direkt darin gedacht und enthält daher auch keine Working Copy, sondern nur die Repository-/Metadaten. Es wird ausschließlich per Konvention zum Hauptrepository erklärt, aus dem man seine Working Copy bezieht und in das man seine Änderungen pusht.

Die Kunden freut es sicher, wenn Entwickler sich nicht gegenseitig mit Forks und konkurrierenden Repositories bekriegen. Deswegen wird man üblicherweise ein Bare Repository erstellen, in das die neuen Funktionen und Anpassungen einfließen und das im Deployment-Prozess eingebunden wird.

Branching und Merging

Das Erstellen von Branches war bereits in SVN flott und problemlos. Was allerdings weit weniger Spaß macht, ist das Mergen (Zusammenführen) von zwei Branches, wenn in den Zweigen umfangreiche Änderungen durchgeführt wurden. Ein typisches Beispiel dafür ist ein Update einer Magento-Installation z.B. von Magento 1.3 auf 1.4. Hier läuft man immer wieder Gefahr, ohne eigenes Verschulden zum Handkuss zu kommen und über Stunden das Repository zu flicken, um wieder zu einem stabilen Zustand zu gelangen. Diese Erfahrung möchte man kein zweites Mal machen. Das ist einer der Hauptgründe, warum der Wechsel zu Git bei uns ein Thema wurde.

Git hingegen hat sich in der Community als äußerst robust erwiesen, wenn es um das Mergen geht. Das ist wichtig, denn Branchen ohne Mergen macht wenig Sinn. Zugleich ist das Verwenden von Entwicklungszweigen in vielen Situationen unerlässlich. Deswegen sollte es sich um eine Aktion handeln, die man gerne einsetzt und bei der man nicht Blut und Wasser schwitzen muss. Ich hoffe stark, dass Git hält, was es verspricht.

Performance

Tausendmal zitiert und immer noch wahr: „Zeit ist Geld“. Wenn man warten muss, dass Operationen ausgeführt werden, geht wertvolle Entwicklungszeit verloren und man tendiert dazu, diese Operationen seltener auszuführen. Das trifft nicht nur auf Aktionen zu, die über Minuten laufen. Bereits im Sekundenbereich wirkt sich das aus. (Erstens summieren sich viele kleine Aktionen über mehrere Entwickler, zweitens nervt es schlicht, wenn etwas 5 Sekunden statt 1 Sekunde dauert.)

Es hat sich gezeigt, dass Git wesentlich schneller als SVN ist. Vor einigen Wochen habe ich einen Geschwindigkeitstest von Git und SVN mit Magento durchgeführt, in dem ihr das nachlesen könnt.

Lesematerial

Ich habe bisher zwei Bücher zu Git gelesen. Das erste Buch, Versionskontrolle mit Git von Jon Loeliger, kann ich wirklich uneingeschränkt allen Git-Neulingen empfehlen. Jon ist Teil des Entwicklungsteams von Git und geht ausführlich auf die Konzepte und Basics von Git ein. Für SVN-Kenner werden immer wieder Vergleiche eingebracht, wodurch man sich leichter zurecht findet. In späteren Kapiteln werden fortgeschrittene Themen aufgegriffen, so dass auch erfahrene User sicher das eine oder andere lernen können.

Das zweite Buch in unserer Sammlung, Git – kurz und gut von Sven Riedel, hält was es verspricht: Git und seine Möglichkeiten werden komprimiert dargestellt.  Das Buch eignet sich nach einer Meinung als Referenz, wenn man bereits etwas Erfahrung mit Git hat. Für den direkten Einstieg ist das Buch für mich zu knapp gehalten: was in „Versionskontrolle mit Git“ über 10 Seiten ausführlich und anschaulich erklärt wird, wird hier oft in einem (kurzen) Absatz abgehandelt. Daher: „Git – kurz und gut“ direkt kaufen, wenn man die Details nicht wissen muss, im Web dazu recherchieren will oder eine extrem schnelle Auffassungsgabe hat. Den anderen empfehle ich, sich „Versionskontrolle mit Git“ zu holen und eventuell „Git – kurz und gut“ als handliche Befehlsreferenz dazu zu holen. Dazu sei noch gesagt, dass ich in ersterem aufgrund des Inhaltsverzeichnisses und der Stichwortliste die Befehle leichter wiederfinde.

Zum Abschluss noch hilfreiche Links:

• Git Reference: entgegen des Namens nicht die offizielle Referenz, sondern ein übersichtliches Tutorial für die ersten Schritte.
• Git-SVN-Crashkurs: stellt die korrespondierenden Git- und SVN-Befehle gegenüber. Hilfreich für Umsteiger.
• Git-Kurzübersicht als Cheatsheet: sieht bei mir ausgedruckt etwas seltsam aus (ohne Registrierung), aber das Cheatsheet ist eine gute Zusammenfassung.

Im nächsten Teil

Teil 3 der Serie wird Ruby und Ruby on Rails unter die Lupe nehmen. Was sagt ein langjähriger PHP- und Zend-Framework-Entwickler zu diesem Gespann?