Es gehört heutzutage für Software-Entwickler zum guten Ton, ein verteiltes Versionsverwaltungssystem, wie zum Beispiel Git, zu verwenden 1. Auch dieser Artikel wird nicht an der Tatsache rütteln, dass Git zu Recht zum etablierten Industriestandard gehört. Doch nicht alle Unternehmen sind gleich schnell im Übernehmen von Standards. Und so findet sich mancher Projektleiter in der Situation wieder, dass ein Auftraggeber noch ein älteres Versionsverwaltungssystem einsetzt. Dieser Artikel soll ein Argumentarium bieten, Entscheidungsträger vom Nutzen von Git zu überzeugen.
Zunächst wird die Funktionsweise von Git in groben Zügen erklärt, dann werden Argumente aus verschiedenen Ebenen dargelegt, die für Git als Versionsverwaltungssystem sprechen.
Funktionsweise
Ein wichtiges Konzept von Git sind Branches (Zweige). Ein Branch teilt eine Entwicklungslinie in zwei Linien auf. Änderungen in einem Branch sind immer lokal und für andere Branches nicht sichtbar. Erst durch das Zusammenführen, Mergen, übernimmt man Änderungen von einem Branch in den anderen Branch. Das Mergen ist eine Operation mit definierter Quelle und Ziel. Wenn der Entwickler zum ersten Mal ein Repository herunterlädt, nennt sich die Operation “clone”. Git ist dezentral konzipiert (jeder kann mit jedem Repository synchronisieren), dennoch setzt man Git üblicherweise so auf, dass ein gemeinsames, zentrales “shared repository” definiert wird, über das sich alle synchronisieren. Ein Benutzer kann nun von einem Repository die neuesten Änderungen beziehen (Operation “pull”), oder publizieren (“push”). Ein Benutzer pflegt Änderungen im lokalen Repository mit “commit” ein, erst durch den “push” sehen andere Benutzer diese Änderung.
Technische Argumente
Git setzt auf eine dezentrale Architektur. Das bedeutet, dass jeder Benutzer eines Repositories immer das komplette Repository klont, und nicht nur Teilbereiche des Repositories. Somit kann der Benutzer die meisten seiner Aufgaben offline erledigen, mit wenigen Ausnahmen (Git Pull und Push). Git ist für die meisten Operationen schnell, gerade dadurch, dass alle Dateien lokal verfügbar sind. Git stellt auch die Datenintegrität sicher: Jeder Versionsstand ist eindeutig anhand der Checksumme der Dateien identifizierbar. Ein Angreifer kann nur mit einem immensen Aufwand die Dateien in Git manipulieren ohne die Checksumme zu verändern. Wie könnte ein Angreifer Erfolg haben? Git verwendet SHA-1 und Google hat im Februar 2017 die erste SHA-1 Hash-Kollision publiziert, welche 6500 Jahre CPU-Zeit für die Berechnung erforderte 2. Doch für diese Schwachstelle wird das Git-Projekt bestimmt eine Lösung finden, um die Datenintegrität wieder voll zu gewährleisten.
Prozessorientierte Argumente
Git unterstützt parallele Entwicklungsprozesse. Die Parallelität gilt nicht nur für das ganze Entwicklungs-Team sondern auch für den einzelnen Entwickler. So kann der Entwickler eine Arbeit beginnen, bei Unklarheiten oder Abhängigkeiten pausieren, ohne den Arbeitsstand zu verlieren, und später wieder fortsetzen. Git schreibt keinen Entwicklungsprozess oder Arbeitsfluss (work flow) vor, sondern lässt dem Benutzer die Wahl bei Branching-Modell, Release-Nummerierung, Code-Review etc. Dennoch lässt sich sagen, dass Git gerade auch ideal für die iterative Entwicklung ist.
Da sich Features mithilfe von Branches als “Pakete” schnüren lassen, die für den nächsten Release an- oder deaktivieren lassen, sind kontrollier- und steuerbare Releases möglich. Der Entwickler und der Projektleiter haben im Vergleich zu anderen Versionsverwaltungssystemen oftmals eine bessere Übersicht von relevanten Änderungen und neu hinzugekommenen Features.
Bei der Analyse des bestehenden Entwicklungsprozesses kann unter Umständen auffallen, dass dieser mangelhaft ist, gerade auch durch die beschränkten Möglichkeiten des bestehenden Versionsverwaltungssystems. Ein Beispiel sind Arbeitsabläufe, bei welchen die Erweiterung und der Unterhalt von Software in einer einzigen Entwicklungslinie vermischt sind. In solchen Fällen muss zum Ziel gesetzt werden, einen besseren Entwicklungsprozess zu erarbeiten, der mit Git ermöglicht wird. Somit werden Entwickler und Projektleiter mit Git befähigt, den Entwicklungsprozess umzusetzen, der für das jeweilige Projekt am sinnvollsten ist.
Betriebswirtschaftliche Argumente
Gerade aus den Argumenten der Prozesssicht resultiert eine erhöhte Arbeitseffizienz und somit tiefere Entwicklungskosten. Unternehmen, die eine Umstellung von anderen Versionsverwaltungssystemen zu Git vornehmen, müssen einen einmaligen Migrations- und Schulungsaufwand gegenrechnen. Durch die höhere Effizienz ergibt sich aber auch ein schnelleres Time-To-Market für neue Features eines Software-Projekts. Durch die erhöhte Steuerbarkeit von Releases ergibt sich auch eine höhere Produktqualität.
Alleinstellungsmerkmale
Es gibt noch andere verteilte Versionsverwaltungssysteme als Git. Da gibt es zum Beispiel auch Mercurial, das ebenfalls dezentral ist und einen ähnlichen Funktionsumfang aufweist. Doch Git geniesst bei Software-Entwicklern eine ungeschlagene Popularität. Da Git einiges im Entwickleralltag vereinfacht und fast alles richtig macht, hat dieses Werkzeug auch eine hohe Akzeptanz.
Technische Limitationen
Es gibt auch Limitationen bei Git, doch damit kann man sich leicht arrangieren. Git verwaltet nur Dateien und keine leeren Ordner. Ordner werden in Abhängigkeit von benötigten Dateipfaden erstellt. Git ist darauf optimiert, sehr viele kleine bis mittelgrosse Dateien in mehreren Branches zu verwalten. Die derzeitige empfohlenen Maximalgrössen sind: 100MB pro Datei, 1GB pro Repository 3. Für grössere Dateien empfehlen sich Erweiterungen wie zum Beispiel Git LFS. Git unterstützt aufgrund der dezentralen Architektur folgerichtig kein Locking. Niemand kann ein exklusives Schreibrecht auf Dateien verlangen. Git kennt von Haus aus keine Zugriffsrechte. Der Zugriff wird mit SSH oder HTTPS-Login geregelt. Sobald es um individuelle Lese- und Schreibrechte geht, sollten Anbieter (GitHub, Microsoft TFS) oder Erweiterungen geprüft werden. 4
Weiteres
Wurde der Entscheidungsträger vom Nutzen von Git überzeugt, sollten Sie einige Dinge beachten und planen:
- Wählen Sie ein Git-GUI (SmartGit, SourceTree, etc.)
- Bestimmen Sie die Repository-Location (GitHub, TFS, On Premises)
- Migrieren Sie das Versionsverwaltungssystem zu Git
- Schulen Sie die Mitarbeiter
- Definieren Sie ein Branching-Modell
Quellen
