Konferenz 10.08.2017, 11:34 Uhr

"git ist so entworfen, dass es Branches sehr zuverlässig zusammenführt."

Wenn selbst auf Webseiten von Microsoft das freie, verteilte Versionskontrollsystem auftaucht, muss es sich dabei um etwas Besonderes handeln. "Ist es auch", sagt Marko Beelmann. dotnetpro sprach mit ihm über git, Branches und Merges.
Marko Beelmann 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 erklärt er den Umgang mit git in seiner Session Push, Pull, Branch, Merge, Rebase! Oh my….
dotnetpro: Ein bisschen hört sich die Beschreibung deiner Session auf der .NET Devleloper Conference so an wie: „Branch mal wieder!“ Ist das denn nicht ein bisschen viel Aufmerksamkeit auf das Verzweigen von Entwicklungsschienen?
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 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 essentiell. Diese Branches sind die lokalen Abbilder der Branches auf der Server-Seite zum Zeitpunkt der letzten Synchronisation.
dotnetpro: Geht das Branchen in Git tatsächlich so einfach? Was muss ich dafür tun?
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 und 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 dann 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.
dotnetpro: Okay, wenn es so leicht geht, ist der Rückweg wahrscheinlich schwer, oder?
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 Checkin 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 zusammenführt. Wurde eine Datei auf zwei Entwicklungszweigen parallel verändert, so kann git aufgrund, seiner Parent-Beziehung den letzten gemeinsamen Commit dieser Datei finden. Mit Hilfe 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.
dotnetpro: Selbst auf Microsofts Team Foundation Services Website steht der Name git. Ist das denn das einzige gute Versionkontrollsystem derzeit?
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 git zum Beipspiel nur sehr schlecht mit binären Dateien umgehen, denn jede neue Version einer binären Datei wird 1:1 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. Dies kann die Performanz von git deutlich einschränken. 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.



Das könnte Sie auch interessieren