„git führt Branches zuverlässig zusammen.“

Ist es auch“, sagt Marko Beelmann. Er ist Softwareentwickler aus Leidenschaft und .NET-Entwickler der ersten Stunde. Seit .NET 1.0 ist er vom Framework und der Sprache C# überzeugt. Außerdem beschäftigt er sich intensiv mit der verteilten Versionsverwaltung git. Auf der .NET ­Developer Conference (www.dotnet-deve loper-conference.de) erklärt er den Umgang damit in seiner Session „Push, Pull, Branch, Merge, Rebase! Oh my ...“

Marko Beelmann: Ein Branch stellt in der Tat nicht unbedingt etwas Spektakuläres dar, allerdings war es in der Vergangenheit oft so, dass Branches eigentlich verhindert werden sollten. Das lag vor allem daran, dass die bisherigen zentralen Versionskontrollsysteme Schwierigkeiten hatten, Branches wieder zusammenzuführen und dass deren Handhabung umständlich war.

git ist hingegen schon von Anfang an für das Branching designt worden. Es macht die Arbeit mit Branches sehr einfach. Die Entwickler werden aber auch beim Zusammenführen der Branches durch git besser unterstützt.

Somit ist es vor allem in agilen Entwicklungsteams nicht unüblich, dass jegliche Änderungen am Code auf eigenen Feature-Branches implementiert werden. So ist die Entwicklung komplett isoliert und der Entwickler kann sich auf die Implementierung seines Features fokussieren.

Durch die Flexibilität des Systems ist es mit git auch möglich, verschiedene Workflows einzusetzen. Daher sollte ein Entwickler wissen, wie mit Branches in git gearbeitet werden kann. Konzepte wie Rebase oder interaktives Rebase können hier als effektive Hilfsmittel genutzt werden. Auch der richtige Umgang mit den sogenannten Remote-Branches ist essenziell. Diese Branches sind die lokalen Abbilder der Branches auf der Server-Seite zum Zeitpunkt der letzten Synchronisation.

Beelmann: Branches sind in git sehr leichtgewichtig, da ein Branch nichts anderes als ein Zeiger auf einen Commit darstellt. Die Historie des Branches leitet sich dann von diesem Commit ab, da jeder Commit einen Verweis auf seinen Vorgänger speichert. Nur der erste Commit in einem Repository besitzt somit keinen Vorgänger-Commit.

Zum Anlegen eines neuen Branches mit dem Namen Feature genügt der Befehl git branch Feature. Damit ist ein neuer Branch erstellt, und zwar auf Basis des aktuell ausgecheckten. Der Wechsel wird dann mit einem git checkout Feature erreicht und es kann sofort auf diesem Branch gearbeitet werden.

Bei einem distribuierten Versionskontrollsystem wie git ist es wichtig zu wissen, dass erst einmal alles lokal stattfindet. Die Übertragung von Änderungen an einen Server ist immer ein expliziter Schritt, der durchgeführt werden muss.

Das hat auch den Vorteil, dass lokal durchaus experimentiert werden kann. Merges oder Rebase können lokal sehr einfach rückgängig gemacht werden.

Beelmann: Immer, wenn mit Branches gearbeitet wird, kann es zu Problemen beim Zusammenführen kommen. Das gilt besonders dann, wenn an einer Datei an der gleichen Stelle auf verschiedenen Branches Änderungen vorgenommen werden. Diese Konflikte kann letztendlich kein Algorithmus lösen. Das Problem tritt aber bei jeder Versionsverwaltung auf und ist somit kein Problem von git. Diese Situation tritt auch nicht nur beim Merge von Branches auf, denn bei den bekannten zentralen Systemen kann diese Situation auch bereits bei einem Check-in vorkommen. Konflikte treten also immer auf und werden auch immer wieder auftreten.

git ist so entworfen, dass es einen Merge von Branches sehr zuverlässig ausführt. Wurde eine Datei auf zwei Entwicklungszweigen parallel verändert, so kann git aufgrund seiner Parent-Beziehung den letzten gemeinsamen Commit dieser Datei finden.

Mithilfe des letzten gemeinsamen Stands ist git nun in der Lage, einen Drei-Wege-Merge ausführen. Dieser Algorithmus ist meist schon so gut, dass er zu dem erwarteten Ergebnis führt.

Neben dem Drei-Wege-Merge kann git auch noch andere Algorithmen bei einem Merge oder Rebase anwenden. Zusammenfassend kann aber der Merge in git im Vergleich zu traditionellen zentralen Systemen als problemlos angesehen werden.

Beelmann: Nein. Der Erfolg von git ist sehr eng mit dem Erfolg von github als Quasi-Standard für das Hosting von Open-Source-Projekten verbunden. Erst durch die Verbreitung von github stieg auch die Verbreitung und Nutzung von git schlagartig.

Viele schätzen vor allem die hohe Geschwindigkeit bei der Arbeit mit git. Da git ein verteiltes System ist, sind alle Operationen lokal und damit sehr schnell. Ob Commit, Merge oder Rebase, für eigentlich alle grundlegenden und wichtigen Funktionen wird keine Verbindung zu einem Server benötigt.

Aber auch git hat Schwächen. So kann es zum Beispiel nur sehr schlecht mit binären Dateien umgehen, denn jede neue Version einer binären Datei wird eins zu eins in dem Repository­ gespeichert. Wenn es sich dabei um große Dateien handelt, kann das Repository sehr schnell wachsen und somit­ sehr unhandlich­ werden. Zwar gibt es für diese Zwecke auch Auswege­ wie das git Large File Storage (LSF), allerdings entspricht­ dies dann nicht ganz dem eigentlich dezentralen Charakter von git.

Ebenso kann die Anzahl der Dateien für git zu einem Problem werden. Wird eine große Zahl von Dateien in ein Repository eingelesen, sinkt die Performance von git. Microsoft hat eigens für dieses Problem ein virtuelles Dateisystem geschrieben, um die Sourcen von Windows in einem git-Repository zu verwalten.

Sollte die aktuelle Versionskontrolle die Arbeit nicht effektiv einschränken, so sollte man sich keine Gedanken über einen möglichen Umstieg machen. Der Wechsel auf git ist nicht ganz unproblematisch, denn vor allem die Entwickler müssen geschult und gecoacht werden.

Die .NET Developer Conference findet vom 28. bis 30. November 2017 in Köln statt. Hier erfahren .NET-Entwickler alles zu Praxis und Anwendung von .NET, C# und Visual Basic sowie zu künftigen Entwicklungen.