Gitflow in der Praxis – Teil 1: Grundlagen der Versionsverwaltung

Das kollaborative Arbeiten an einer gemeinsamen Codebasis in der Praxis stellt verschiedene Herausforderungen an Softwareentwickler. Die von den einzelnen Entwicklern durchgeführten Änderungen müssen zusammengeführt werden und sollen nachvollziehbar sein. Wenn beim Programmieren ein Fehler gemacht wurde, ist es manchmal erforderlich, auf einen definierten, funktionsfähigen Codestand zurückgehen zu können.

Eine weitere Herausforderung ist, dass unter Umständen auch ältere Versionen erweitert oder verändert werden müssen. Zum Beispiel, wenn das Bereitstellen eines Hotfix erforderlich wird. Um diese Aufgaben zu lösen, werden Versionsverwaltungssysteme (VCS) eingesetzt. In diesem Teil der Artikelserie werden die Grundlagen umrissen, die für das Verständnis des Gitflow Workflows erforderlich sind. Eine kurze Erläuterung der wichtigsten Begriffe ist am Ende des Artikels zu finden.

Zentrale und verteilte Versionsverwaltungssysteme

Versionsverwaltungssysteme (VCS) kamen schon sehr früh in der Softwareentwicklung zum Einsatz. Bereits in den 1970er Jahren enthielt Unix das Source Code Control System (SCCS) zur Versionsverwaltung¹. Bei den VCS kann grundsätzlich zwischen zentralen und verteilten (dezentralen) Systemen unterschieden werden. Das gängigste zentrale VCS ist das Apache Projekt Subversion (SVN), welches nach wie vor in vielen Unternehmen zum Einsatz kommt. Das von Linus Torvalds entwickelte Git hat sich bei den verteilten Versionsverwaltungen durchgesetzt². Die folgenden Abschnitte bieten einen kurzen Überblick zu den Unterschieden beider Ansätze:

Zentrale Versionsverwaltungssysteme

Bei den zentralen Versionsverwaltungen kommt eine Client-Server-Architektur zum Einsatz. Der Server stellt ein zentrales Repository bereit, auf dem der gesamte Quellcode und seine Historie verwaltet wird. Als Entwickler kann man eine durch die Versionsnummer spezifizierte Revision auf seinen Computer (Client) aus dem zentralen Repository auschecken. Der Client erhält dadurch den Quellcode auf dem gewünschten Stand, jedoch nicht die Historie der Entwicklung.

Führt ein Entwickler auf seinem Gerät (Client) Änderungen am Code durch und möchte sie in die Historie einfügen, geschieht dies in Form eines Commits. Bei den zentralen VCS wird jeder Commit in das zentrale Repository übertragen (Einchecken / Check-In). Es wird die Differenz zwischen dem neuen Codestand und dem Stand im Repository übermittelt. Dies ist jedoch nur möglich, wenn man die erforderlichen Berechtigungen für das zentrale Repository besitzt.

Falls von zwei Entwicklern gleichzeitig Änderungen an der selben Datei vorgenommen wurden, entsteht ein Konflikt. Dies wurde bei älteren Systemen, z. B. SCCS und RCS dadurch gelöst, dass eine Datei während der Bearbeitung gesperrt wurde, sodass zur gleichen Zeit immer nur ein Entwickler an einer Datei arbeiten konnte³. Neuere Systeme bieten die Möglichkeit, einen Konflikt durch Nachbearbeitung der betroffenen Datei aufzulösen und die Lösung in das Repository einzuchecken.