Gitflow in der Praxis – Teil 1: Grundlagen der Versionsverwaltung

Das kollaborative Arbeiten an einer gemeinsamen Codebasis 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 Versionsverwaltung1. 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 durchgesetzt2. 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 konnte3. Neuere Systeme bieten die Möglichkeit, einen Konflikt durch Nachbearbeitung der betroffenen Datei aufzulösen und die Lösung in das Repository einzuchecken.

Du suchst eine neue Herausforderung in der App- und Webentwicklung?

Bei moguru kannst Du im Team mit erfahrenen Entwicklern kennenlernen, wie Gitflow in spannenden Softwareprojekten unter Einsatz modernster Technologien umgesetzt wird.

Hier geht's zu unseren aktuellen Stellenangeboten.

Bei Fragen rund um die moguru steht Dir Reihana Sarif gerne persönlich zur Verfügung.
+49 6151 6292715mitmachen@moguru.de

reihana

Verteilte Versionsverwaltungssysteme

Diese Artikelserie erläutert das Arbeiten mit Gitflow, einem Arbeitsablauf, der speziell für Git entwickelt wurde. Git ist ein verteiltes, dezentrales System. Auch bei den verteilten VCS gibt es in der Regel einen Server, der den gesamten Quellcode und dessen Änderungshistorie (Repository) bereitstellt.

Die Historie entsteht, indem auf einem initialen Codestand (initial commit) aufgebaut wird. Das Repository wird durch das einchecken des ersten Codestandes, zum Beispiel eines neu erstellten Softwareprojektes initialisiert. Das Einchecken erfolgt immer in Form eines Commits, welcher den gesamten bei der Erstellung des Commits bestehenden Quellcode repräsentiert. Anhand einer Prüfsumme und eines Kommentars ist der Commit eindeutig identifizierbar.

Werden darauf folgend Änderungen am Quellcode vorgenommen, zum Beispiel das Erweitern um ein neues Feature, dann wird dieses als weiterer Commit in das Repository eingecheckt. Ein neuer Commit enthält neben seiner eigenen Prüfsumme auch immer die Prüfsumme seiner Vorgänger, sodass eine Kette entsteht, die in beiden Richtungen nachvollzogen werden kann. Dies sorgt neben der Nachvollziehbarkeit für die Integrität der Daten, da die Historie nicht manipuliert werden kann, ohne dass sich sämtliche Prüfsummen der auf die Manipulation folgenden Commits ändern.

Im Gegensatz zu den zentralen VCS wird beim Checkout nicht nur eine bestimmte Revision heruntergeladen, sondern das gesamte Repository inklusive seiner Historie. Jeder Entwickler hat somit ein unabhängiges, voll funktionsfähiges und prinzipiell gleichberechtigtes Repository auf seinem Computer, mit dem er ohne Verbindung zum Server arbeiten kann. Dies bietet eine hohe Flexibilität während der Entwicklung.

Die gesamte Funktionalität des VCS steht lokal zur Verfügung. Es können beliebig lokale Branches erstellt, verändert und gelöscht werden. Auf diesen Branches ist das Committen ohne Verbindung zum Server möglich. Des Weiteren sind dafür keine Berechtigungen im zentralen Repository erforderlich, sodass jeder Entwickler frei am Quellcode arbeiten kann. Berechtigungen spielen erst eine Rolle, wenn die lokal durchgeführten Änderungen an das zentrale Repository übertragen (Push) werden sollen.

Dezentrale VCS bieten deutliche Vorteile gegenüber zentralen Systemen, insbesondere beim kollaborativen Arbeiten im Team. Die Zusammenarbeit wird durch das Arbeiten mit lokalen, unabhängigen Branches erleichtert und lässt Spielraum für experimentelle Features, unabhängige Weiterentwicklungen und ein Ändern von bestehendem Code ohne Risiko. Wenn Du diese Vorteile persönlich beim Arbeiten in modernen und spannenden Projekten kennenlernen möchtest und Spaß an der Arbeit im Team hast, dann sende jetzt Deine Bewerbung an die moguru GmbH. Hier geht es zu unseren aktuellen Stellenangeboten.


Übersicht: zentrale vs. dezentrale Versionsverwaltungssysteme (VCS)


Zentrale VCS:

  • Netzwerkverbindung zum Server erforderlich
  • Geringe Geschwindigkeit (durch Netzwerkkommunikation bei jeder Aktion, die eine Verbindung zum Repository erfordert)
  • Locking bei älteren Systemen erschwert kollaboratives Arbeiten
  • Schreibrechte auf Repository erforderlich, um partizipieren zu können
  • Vollständige Historie liegt nur auf dem Server
  • Fehler oder Löschen des Repository auf dem Server verursacht umfassenden Datenverlust


Dezentrale VCS:

  • Vollständige Kopie auf allen Clients
  • Arbeiten ohne Netzwerkverbindung ist möglich, nachträgliches einchecken der Änderungen unproblematisch
  • Forken und zurück mergen unproblematisch, deshalb Pull Requests möglich
  • Jeder Client hat eine vollständige Kopie des Repository inkl. der gesamten Historie
  • Sicherung der Integrität der Daten durch Prüfsummen

Begriffsklärung

Repository
Die gesamte Codebasis inkl. ihrer Änderungshistorie

Commit
Eine (atomare) Änderung an der Codebasis, zum Beispiel das Hinzufügen einer neuen Datei

Branch
Ein Zweig, welcher einen oder mehrere Commits enthält und von dem Ursprung abstammt

Master Branch / Trunk
Die Hauptlinie der Entwicklung, welche den Ursprung des Quellcode (initial commit) enthält

Hotfix
Kurzfristige Fehlerbehebung einer Software-Version, die aufgrund ihrer Dringlichkeit zwischen zwei Releases als Update / Patch veröffentlicht wird

Merge
Das Zusammenführen zweier Branches und ggf. das Auflösen von Konflikten

Check-In / Einchecken
Übertragen von Branches und Commits aus dem lokalen in das zentrale Repository

Check-Out / Auschecken
Herunterladen des zentralen Repository, einzelnen Branches oder einzelner Commits


Quellen

¹ GLASSER, Alan L. The evolution of a source code control system. ACM SIGSOFT Software Engineering Notes, 1978, 3. Jg., Nr. 5, S. 122-125. 

² https://rhodecode.com/insights/version-control-systems-2016 

³ http://www.gnu.org/software/emacs/manual/html_node/emacs/VC-With-A-Locking-VCS.html 

 

Moritz...

... der für einen einheitlichen und durchdachten Workflow kämpft.

Moritz Pfaff hat Informatik und Mobile Computing studiert und arbeitet als Android Entwickler bei der moguru. Er beschäftigt sich mit der sauberen Umsetzung von Android Apps in Kotlin.