René Preißel und Bjørn Stachmann: Git

René Preißel und Bjørn Stachmann: Git

René Preißel, Bjørn Stachmann
Git Dezentrale Versionsverwaltung im Team. Grundlagen und Workflows.

5. aktualisierte und erweiterte Auflage
August 2019, xxii, 337 Seiten, Broschur
dpunkt.verlag
ISBN: 978-3-86490-649-7

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Die erste Auflage des Buches Git von René Preißel und Bjørn Stachmann erschien im Jahre 2012. Mittlerweile sind wir bei der fünften Auflage des erfolgreichen Buches angelangt. Das Thema – das Versionskontrollverwaltungstool Git – ist heute genauso relevant, wie es damals war.


Struktur

Das Buch Git ist in fünf Hauptteile unterteilt. Der erste Teil Erste Schritte dient als eine Art erweiterte Einleitung, von der zu Arbeiten mit Git übergegangen wird, wo der Leser erfährt, wie Git zu verwenden ist.

Im dritten Hauptteil Workflows werden mögliche Arbeitsläufe vorgestellt. Diese sind in weitere drei Unterteile gegliedert:

  • Entwickeln mit Git,
  • Release-Prozess,
  • Repositorys pflegen.

Den Schluss des Buches bilden weiterführende Themen im Teil Mehr über Git dem der Anhang folgt.

Inhalt

Die Autoren beginnen das Buch einer kurzen Erörterung der Frage „Warum Git?“, die unter anderen mit folgenden Argumenten beantwortet wird:

  • einfaches Arbeiten mit Branches
  • Performanz
  • Dezentrale Architektur.

Das erste Kapitel Grundlegende Konzepte definiert wichtige Begriffe und geht kurz auf Spezifika verteilter Versionsverwaltungssysteme ein. Neben Branching und Merging werden auch Repository-Typen beschrieben:

  • Blessed Repository
  • Shared Reopsitory
  • Workflow Repository
  • Fork Repository.

Erste Schritte

Git hat seinen Ursprung in der Linux-Welt. Wenig verwunderlich wird entsprechend im zweiten Kapitel die Einrichtung und Verwendung über die Kommandozeile vorgestellt. Ganz nebenbei lernt der Leser die ersten Befehle kennen: init, add, commit, diff, log, clone, u.a. Die Vorgänge des Pushens und Pullens finden ebenfalls Erwähnung.

Im dritten Kapitel wird anhand der gleichen Schritte, wie im zweiten Kapitel, das graphische Tool SourceTree vorgestellt.

Arbeiten mit Git

Mit dem vierten Kapitel Was sind Commits? beginnt der zweite Teil des Buches betitelt Arbeiten mit Git. Commits werden dabei als der „wichtigste Begriff in Git“ (S. 31) bezeichnet. Die Befehle add und commit aber auch show und log werden näher beschrieben.

In Commits zusammenstellen lernt der Leser über Staging und Stashing und über die Möglichkeit Dateien und Verzeichnisse mittels .gitignore von der Versionierung auszuschließen.

Das sechste Kapitel Das Repository geht kurz auf die Implementierung der Datenhaltung in Git ein.

Branches sind ein integraler Bestandteil der Arbeit mit Git, entsprechend früh wird dieses Thema angegangen. In Branches verzweigen werden die Befehle branch, checkout und reset beschrieben und in Branches zusammenführen werden die unterschiedlichen Arten des Mergeings und den Umgang mit Merge-Konflikten vorgestellt.

Im darauffolgenden Kapitel wird auf die Themen Rebasing und Cherry Picking eingegangen. Kapitel 10 diskutiert eingehender das Thema Repositorys und Kapitel 11 geht auf die Befehle zum Austausch zwischen Repositorys ein: fetch, pull und push.

Tags und das Reflog werden in den beiden letzten Kapiteln des zweiten Teils besprochen.

Workflows

Aufgrund der Komplexität und Vielseitigkeit von Git sind je nach Use Case verschiedene Workflows möglich und sinnvoll. Ebenfalls ist es wichtig zu wissen, dass das gleiche Ziel über unterschiedliche Wege erreicht werden kann. Im dritten Teil gehen die Autoren auf zwölf Use Cases ein und beschreiben jeweils einen geeigneten Workflow dafür. Die Workflows folgen dem gleichen Aufbau:

  • Überblick verschaffen,
  • Beschreibung oder Auflistung der Voraussetzungen,
  • konkreter Ablauf und die Umsetzung
  • und zum Schluss eine Diskussion der möglichen Alternativen.

Folgende Workflows/Use Cases werden besprochen:

  1. Aufsetzen eines frischen Projektes
  2. Gemeinsame Entwicklung mehrerer Entwickler auf einem Branch
  3. Verwendung von Feature-Branches
  4. Arbeiten mit Forks
  5. Continuous Deployment
  6. Periodische Releases
  7. Mehrere gleichzeitig gewartete Software-Versionen
  8. Versionierung von binären Dateien
  9. Splitten großer Projekte
  10. Zusammenführen von Projekten
  11. Auslagerung von Historien
  12. Migration von Projekten nach Git.

Wegen der sehr technischen und schwer zusammenfassbaren Thematik wird hier nicht näher auf die einzelnen Workflows eingegangen.

Mehr über Git

Im letzten Teil Mehr über Git werden teils Beziehungen zu anderen Tools (Integration mit Jenkins) und teils speziellere Anwendungsfälle, wie der Umgang mit großen Repositorys oder die Arbeit mit Subtrees und Submodulen, besprochen.

Im letzten Kapitel Die Grenzen von Git schließt sich der Bogen, der mit der initialen Frage eröffnet wurde. Es geht nun um die Frage „Warum nicht Git?“ Die Autoren geben mehrere Antworten auf diese Frage, unter denen die hohe Komplexität des Tools wahrscheinlich die wichtigste davon ist.

Anhang

Im Anhang sind noch zwei Verzeichnisse zu finden: das Verzeichnis der Schritt-für-Schritt-Anleitungen und das der Workflows (jeweils mit einer Kurzübersicht).

Diskussion

An Git als Versionsverwaltungstool führt heutzutage kein Weg mehr vorbei. Sollte man sich für ein anderes Versionskontrollsystem entscheiden – z.B. für das etwas betagtere Subversion – wird sich fast zwangsläufig jemand finden, der die Frage stellt: „Warum nicht Git?“

Für den Einsatz eines verteilten Versionsverwaltungstools im Allgemeinen und den Einsatz von Git im Speziellen gibt es viele gute Gründe. Dagegen spricht ganz klar die einhergehende (potenziell einschüchternde) Komplexität. Dieses Thema wird von den Autoren im letzten Kapitel auch kurz angegangen.

Oft stellt sich jedoch nicht die Frage, welche Versionskontrolle man verwenden will, sondern welche man verwenden muss. Dann wird man sich wahrscheinlich auch weniger mit mehr oder minder „philosophischen“ Fragen befassen wollen, sondern mit der Frage “Wie kann man effizient mit dem neuen Tool umgehen?“ Das Buch Git von René Preißel und Bjørn Stachmann konzentriert sich eben auf diese pragmatischen Fragen: „wie man Git in typischen Projektsituationen einsetzen kann, z.B. wie man ein Git-Projekt aufsetzt oder wie man mit Git ein Release durchführt“ (S. x – eigene kursive Hervorhebungen). Gemessen daran, ist das Buch gut gelungen. Vor allem die Darstellung der unterschiedlichen Workflows kann sehr hilfreich sein – vorausgesetzt, dass der eigene Use Case bekannt und klar definiert ist. Ein Projekt nach Git migrieren erscheint mir dabei als sehr wichtiger Workflow, weil er gut zeigt, dass die Migration eines Projektes alles andere als trivial sein kann und deswegen die „philosophischen“ Fragen doch eine gewisse pragmatische Relevanz haben.

Was dem Buch aber teilweise fehlt, ist mehr Kontext: die geschichtliche Entwicklung von Git, eine bessere Herausarbeitung der Vor- und Nachteile dieser Anwendung und mehr Informationen über die Verwendung von Git in Verbindung mit anderen Tools.

Zwar wird, wie in der Zusammenfassung erwähnt, auf Vor- und Nachteile von Git eingegangen, die Art und Weise wie das getan wird, wirkt jedoch etwas voreingenommen. So werden das Arbeiten mit Branches und die starke Open-Source-Community (vgl. S. vii f.) als für Git sprechende Gründe angesehen, diese Argumente gelten jedoch auch für andere Tools (z.B. für Subversion, auch wenn beim Branching Unterschiede existieren). Ebenfalls sind die Flexibilität und die einfache Administrierbarkeit so wie von den Autoren beschrieben, zweischneidige Schwerter, die zur Erhöhung der Komplexität beitragen.

Die Diskussion von Git im Kontext der Build-Server-Thematik ist sinnvoll. Weiterer Build-Server außer Jenkins zu berücksichtigen wäre sicherlich ebenfalls nützlich (siehe Kapitel 28). Die Integration von Git in Gradle oder Maven sind weitere hilfreiche Themen. Im „Kapitel 26“ – dem „fehlenden Kapitel“ des Buches – eigentlich ein Verweis auf den Blog der Autoren zum Thema Git, gibt es einen Artikel bezüglich der Zusammenarbeit von Gradle und Git.

Ein weiterer Kritikpunkt ist die nicht ganz konsequente Struktur, was öfters zu einem berechtigten Déjà-vu-Gefühl führt. Schon behandelte Themen werden manchmal wiederaufgenommen, in manchen Fällen sind sogar wortgleiche Passagen zu finden (z.B. ist der Paragraf „Sicherheitskopie nicht vergessen!“ wortgleich auf den Seiten 12 und 24 zu finden). Ebenfalls ist es unklar weswegen (fast) jedes Mal, wenn ein Tool im Text erwähnt wird, die Homepage des Tools als Fußnote angegeben wird. So ist die Subversion-Website mindestens acht Mal als Fußnote zu lesen.

Alles in allem ist René Preißels und Bjørn Stachmanns Buch gut brauchbar für das Erlernen von Git. Es empfiehlt sich jedoch für einen besseren Lernerfolg – wie bei technischen Büchern üblich – das Gelernte auch gleich anzuwenden.


Zu den Autoren

René Preißel ist freiberuflicher Software Architekt, Entwickler und Trainer.

Bjørn Stachmann ist Entwickler und hatte die Rollen des Software Architekten, Entwicklers und Beraters in seiner bisherigen Karriere inne.

Qullen: Die Informationen über die Autoren sind jeweils ihren Xing-Profilen (René Preißel, Bjørn Stachmann) entnommen – letzter Zugriff am 19.05.2020.


Folgende Bücher könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar