Versionsverwaltung: Git, Branches und Teamarbeit

Stell dir vor, ein Team ändert gemeinsam dieselben Dateien. Ohne Ordnung weiß bald niemand mehr, wer was geändert hat. Eine Versionsverwaltung löst das: Sie sichert alle Versionen von Dateien in einem Archiv, und zwar mit Zeitstempel und Benutzerkennung. So können die Versionen später wiederhergestellt werden.

Weil zu jedem Versionswechsel Verfasser und Uhrzeit festgehalten werden, kann man genau nachvollziehen, wer wann was geändert hat. Bei Bedarf, zum Beispiel bei versehentlichen Änderungen, kann man zu einer früheren Version zurückkehren.

Zu den Hauptaufgaben gehören außerdem, die einzelnen Stände eines Projektes zu archivieren, alte Stände einzelner Dateien wiederherzustellen und den gemeinsamen Zugriff mehrerer Entwickler auf die Dateien zu koordinieren. Versionsverwaltungssysteme werden typischerweise in der Softwareentwicklung eingesetzt, um Quelltexte zu verwalten.

Git geht noch einen Schritt weiter. Der Hash-Wert (eine Art Prüfsumme) eines Commits, also eines gesicherten Standes, hängt von der vollständigen Historie ab, die zu ihm geführt hat. Deshalb ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Hash-Wert ändert. Die Daten gelöschter und zurückgenommener Aktionen und Entwicklungszweige bleiben vorhanden und können wiederhergestellt werden, bis sie explizit gelöscht werden.

Beim Arbeiten mit Git gibt es mehrere Orte. Im Arbeitsverzeichnis liegen die Dateien, an denen du arbeitest. Es kann mit Dateien gefüllt sein, während das Repository (englisch für Behälter, Aufbewahrungsort) noch leer ist. Das Repository ist der Ort, an dem die Dateien des Versionsverwaltungssystems abgelegt sind.

Dazwischen liegt der Staging-Bereich. Er ist die Vorstufe zum Commit. Dorthin fügst du die zu sichernden Dateien mit git add hinzu. Staging und Index sind zwei Namen für denselben Begriff; auf Deutsch heißt er Bereitstellungsraum oder Sammelplatz. Mit git commit kommen die Dateien aus dem Staging-Bereich ins Repository. Danach ist das Repository gefüllt und der Staging-Bereich wieder leer.

In Git besitzt jeder Benutzer eine lokale Kopie des gesamten Repositorys inklusive der Versionsgeschichte. Deshalb können die meisten Aktionen lokal und ohne Netzwerkzugriff ausgeführt werden. Nach einem Commit befinden sich die Änderungen zunächst nur auf dem lokalen Rechner. Ein Remote Repository (entferntes Repository) ist ein Repository an einem anderen Ort, etwa auf einem USB-Stick, einer externen Festplatte oder einem Server. Erst ein Push, zum Beispiel mit git push origin main, überträgt den Commit in ein anderes Repository. Der Name origin ist dabei Konvention, aber nicht Pflicht.

In verteilten Systemen gibt es üblicherweise ein offizielles Repository, das neue Projektbeteiligte zu Beginn klonen, also auf ihr lokales System kopieren.

Ein Branch (Zweig) ist eine Verzweigung zu einer neuen Version. So können unterschiedliche Versionen parallel im selben Projekt weiterentwickelt werden. Branches können zum Beispiel für neue Hauptversionen, für unterschiedliche Betriebssysteme oder für experimentelle Versionen erstellt werden. Der Hauptentwicklungszweig heißt oft Trunk (zum Beispiel bei Subversion) oder Main, früher Master (zum Beispiel bei Git).

In Git ist ein Branch ein Zeiger auf einen Commit, nur eine Textdatei mit einer Commit-ID. Mit git branch neuerbranch legst du einen neuen Branch an. Ein bestimmter Stand kann außerdem mit einem Tag, einem frei wählbaren Bezeichner, gekennzeichnet werden, zum Beispiel v1.0. Wird ein Zweig in einer neuen, unabhängigen Versionsverwaltung erstellt, spricht man von einem Fork. Das ist etwas anderes als ein Branch.

Änderungen können von einem Branch in einen anderen einfließen. Das heißt Merging (verschmelzen). Mit git merge neuerbranch holst du die Änderungen eines Branches in den aktuellen Branch. Das Ergebnis ist ein einziger Datenbestand, der alle Aspekte der verschiedenen Versionen vereinigt. Bei verteilter Versionsverwaltung kommt es nicht zu einem Konflikt, wenn mehrere Benutzer dieselbe Version einer Datei ändern: Die sich widersprechenden Versionen existieren zunächst parallel und können später in eine neue Version zusammengeführt werden. Anders ist es bei Lock Modify Write: Dort werden Dateien vor einer Änderung gesperrt, und man muss unter Umständen auf die Freigabe eines Dokuments warten.

In vielen Fällen gelingt ein Merge automatisch, ohne menschliche Interaktion. Betreffen verschiedene Änderungen aber das gleiche Subset (den gleichen Teil) eines Datenbestandes, kommt es zu einem Merge-Konflikt. Er kann nur manuell aufgelöst werden. Git meldet dann: „Automatic merge failed; fix conflicts and then commit the result.“ In der Datei steht ab der Markierung „<<<<<<< HEAD“ die Fassung des aktuellen Branches. Du musst von Hand eingreifen und die gewünschte Änderung in der Datei ausführen. Viele Versionsverwaltungssysteme werden mit grafischen Hilfsprogrammen ausgeliefert, die das Mergen vereinfachen sollen. Bei Binärdateien können Änderungen oft nicht automatisch zusammengeführt werden, sofern kein passendes Werkzeug verfügbar ist.

Im Team willst du einen Beitrag so ins Projekt bringen, dass andere ihn nachvollziehen können. In der Softwareentwicklung werden meist einzelne Features oder Gruppen von Features in separaten Versionen entwickelt. Bei größeren Projekten überprüfen und führen Personen mit einer Integrator-Rolle diese Versionen zusammen.

Ein möglicher Ablauf: Erstens entwickelst du die Änderung in einem eigenen Branch und committest sie. Zweitens überträgst du den Branch per Push in das gemeinsame Repository, im Beispiel mit git push --set-upstream origin nb. Drittens stellst du auf einer Plattform einen Pull-Request. Viertens begutachten andere Personen die Änderung (Review). Fünftens wird nach dem Akzeptieren gemergt; bei einem Konflikt löst du ihn manuell. Sechstens landet die Änderung im Hauptbranch, wo automatisch ein Build- und Testzyklus startet.

Bevor der geänderte Code in die Basisversion einfließt, kann er von anderen Personen begutachtet und verbessert werden. Beim Code-Review liest ein Gutachter einen Programmabschnitt Korrektur, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Er darf den Code nicht selbst geschrieben haben. Auf Plattformen wie GitHub, GitLab oder Bitbucket lässt sich festlegen, dass eine Mindestanzahl an Reviewern eine Änderung für gut befunden haben muss, bevor sie in den restlichen Code integriert werden darf.

Bei kontinuierlicher Integration sollte jeder Entwickler seine Änderungen so oft wie möglich in die gemeinsame Code-Basis integrieren. Kurze Integrations-Intervalle verringern das Risiko fehlschlagender Integrationen. Der Merge-Aufwand wird immer größer, je länger man mit der Integration wartet. Jede Integration soll einheitlich definierte Tests durchlaufen, bevor die Änderungen integriert werden. Der Test-Zyklus vor der Integration sollte kurz gehalten sein; weniger wichtige Tests werden dann nur nach der Integration durchgeführt.