056.2 Lektion 1

Das Source Code Management System ist das Herzstück eines Softwareprojekts. Obwohl wichtige Arbeiten in Diskussionsforen und an anderen Stellen stattfinden, repräsentiert das SCM-System sowohl die Geschichte des Projekts als auch seinen aktuellen Stand als dynamische Einheit.

Das Repository des Quellcodes ist eine Art digitale Werkstatt für ein Projekt: Wie in einer physischen Werkstatt alle Werkzeuge und Materialien aufbewahrt werden, die zur Herstellung eines Werkstücks benötigt werden, so sind in einem Source Code Repository alle Dateien, Dokumente und der Code des Softwareprojekts gespeichert. Es bietet eine strukturierte Umgebung für Organisation und Verwaltung der Projektressourcen.

Informationen werden in der Regel in Form eines Verzeichnisbaums gespeichert. SCM-Systeme setzen meist auf ein Client-Server-Modell, bei dem jeder Benutzer Daten aus dem Repository abrufen und in das Repository einpflegen kann. Das System zeichnet auf, wer wann welche Änderungen vorgenommen hat, und sorgt so für Transparenz und Verantwortlichkeiten innerhalb des Teams.

Stellen Sie sich vor, Sie arbeiten an einem Projekt mit mehreren Entwicklern und es wird ein Fehler im Code entdeckt. Mit einem SCM können Sie ganz einfach die Änderungen zwischen den Versionen untersuchen und die spezifische Änderung am Code ermitteln, die zu dem Fehler geführt hat.

Da sich das System jede Version einer Datei merkt, sobald sie sich ändert, hat ein Benutzer Zugriff auf jede dieser Versionen und kann zu früheren Versionen zurückkehren (falls beispielsweise falsche Änderungen vorgenommen wurden). Das Repository ist also auch eine Art Archiv, das Zugriff auf jede Änderung, die jemals an dem Projekt vorgenommen wurde, und auf den Status des Projekts zu jedem Zeitpunkt in seiner Geschichte gewährt.

SCM-Systeme sparen Platz, indem sie die Änderungen an einer Datei nachverfolgen, anstatt bei jeder Änderung die gesamte Datei zu speichern. Diese effiziente Speichermethode sorgt dafür, dass frühere Versionen zugänglich sind, ohne übermäßig viele Ressourcen zu verbrauchen.

Viele Tools, wie etwa Continuous Integration/Continuous Delivery (CI/CD) und Testing, sind eng mit dem SCM-System verbunden. Außerdem bauen die Mitwirkenden ihre Reputation über das System auf, indem sie ihre Beiträge für alle sichtbar machen. Bei der Verwaltung des Quellcodes geht es also nicht nur darum, Änderungen zu verfolgen, sondern auch darum, die Integrität der Codebasis zu bewahren und die Zusammenarbeit zwischen den Entwicklern zu fördern; so ist sichergestellt, dass sich Projekte dynamisch unter sich ständig verändernden Bedingungen weiterentwickeln können.

Beliebte SCM-Systeme sind Git, Subversion und CVS. Wie viele andere Softwarefunktionen wird SCM heute oft von spezialisierten Anbietern bereitgestellt. Mit anderen Worten, es handelt sich um Software as a Service (SaaS) oder einen “Cloud”-Dienst: Die Mitwirkenden haben die Software auf ihren lokalen Systemen, um ihre persönlichen Änderungen zu verwalten, laden ihre Änderungen aber in ein zentrales Repository hoch, das von typischen Cloud-Funktionen wie 24/7-Betriebszeit, Backups und sicherem Zugriff profitiert.

Millionen von Entwicklern nutzen inzwischen Cloud-Dienste, insbesondere GitHub. GitLab ist eine Alternative, die auf Open Source Code basiert. Sowohl GitHub als auch GitLab ermöglichen es, in den Cloud-Repositories des Anbieters zu arbeiten oder eine lokale Installation des SCM-Systems einzurichten. Ein Vorteil der Arbeit in diesen Systemen ist die Reputation, die man durch “Sterne” erwerben kann, indem andere Benutzer die eigene Arbeit bewerten. Cloud-Dienste bieten weitere Extras, wie Tracker für Änderungsanforderungen, Bewertungssysteme, Wikis und Diskussionsforen.

Repositories können sowohl persönliche als auch Unternehmensprojekte enthalten, sie sind also keineswegs auf ein kommerzielles Umfeld beschränkt. Jeder Entwickler, der ein Projekt starten oder an einem Open-Source-Projekt arbeiten und es nach seinen Bedürfnissen kopieren und verändern möchte, kann dies tun. In all diesen Fällen ist es wichtig, genau zu kontrollieren, wer auf das Repository zugreifen darf.

Um sich in der Versionskontrolle und dem Source Code Management zurechtzufinden, ist es wichtig, die Begrifflichkeiten zu kennen. In den folgenden Abschnitten werden wir darum einige dieser Konzepte und Begriffe klären.

Ein Entwickler erstellt jedes Mal einen Commit, wenn er eine Änderung in das Respository überträgt. Commits stellen Momentaufnahmen von Änderungen dar, die zu einem bestimmten Zeitpunkt an der Codebasis vorgenommen wurden. Jeder Commit enthält Metadaten wie den Namen des Autors, einen Zeitstempel und eine beschreibende Nachricht, die die Änderungen erläutert. Commits helfen Entwicklern, die Entwicklung der Codebasis nachzuverfolgen und die Geschichte bestimmter Änderungen zu verstehen.

Stellen Sie sich ein Team von Entwicklern vor, die an einer Webanwendung arbeiten. Jedes Mal, wenn sie Änderungen an der Codebasis vornehmen, erstellen sie einen Commit, um diese Änderungen zu dokumentieren. Zum Beispiel könnte jemand, der eine neue Funktion zur Anwendung hinzufügt, einen Commit mit einer Nachricht wie “Funktion zur Benutzerauthentifizierung hinzugefügt” erstellen. Dieser Commit erfasst den Zustand der Codebasis, nachdem die Funktion implementiert wurde.

Behebt ein Entwickler einen Fehler, bezieht sich die Commit-Nachricht normalerweise auf die Nummer des Fehlers im Bug Tracking System, der Fehlerdatenbank, des Projekts.

Tags sind benannte Verweise auf bestimmte Commits. Sie markieren typischerweise wichtige Punkte in der Projektgeschichte, wie beispielsweise Releases oder Milestones. Tags bieten eine Möglichkeit, wichtige Versionen der Codebasis zu kennzeichnen und darauf zu verweisen, was die Verwaltung und Navigation in der Projektgeschichte erleichtert.

Branches, also Zweige oder Abzweigungen, kommen ins Spiel, wenn Entwickler gleichzeitig an sich überschneidenden Aufgaben arbeiten müssen. Branches sind unabhängige Entwicklungslinien, die von der Hauptcodebasis abweichen. So können Entwickler isoliert an Funktionen oder Korrekturen arbeiten, ohne den Hauptcode zu beeinflussen, bis die Änderungen für die Integration bereit sind. Branches helfen, die Entwicklungsarbeit zu organisieren, und erleichtern die Zusammenarbeit zwischen den Teammitgliedern.

Wenn zum Beispiel ein Entwickler an einer neuen Funktion für die Anwendung arbeitet, während ein anderer einen Fehler behebt, kann jeder von ihnen einen eigenen Branch erstellen, um die Änderungen zu isolieren. Sobald ihre Arbeit abgeschlossen ist, können sie ihre Zweige wieder in der Hauptcodebasis zusammenführen, was als Merge bezeichnet wird (Branches).

Wenn mehrere Personen an der gleichen Datei arbeiten oder Dateien in einen anderen Branch überführen, kann es vorkommen, dass sie Änderungen an derselben Zeile einer Datei vornehmen. Wenn die zweite Person ihre Änderungen wieder zurück in das Projekt zu übertragen versucht, meldet das System einen Konflikt.

Einige Versionskontrollsysteme lassen es nicht zu, dass ein Entwickler eine Datei eincheckt, solange sie in Konflikt mit der aktuellen Version im Repository steht. Der Entwickler muss dann die aktuelle Version auschecken, den Konflikt lösen und eine neue Version einchecken.

Cloud-basierte Systeme bieten Merge oder Pull Requests. Diese werden von einem Entwickler erstellt, der in einem lokalen System oder Branch gearbeitet hat und glaubt, dass seine Änderungen für die Aufnahme in einen anderen Branch geeignet sind. Die Entwickler des Zielzweigs entscheiden dann, ob sie die Anfrage annehmen.

Oft wird für die Entwicklung eines Softwareprojekts (beispielsweise eine komplexe Website) der Code eines anderen, unabhängigen Projekts (etwa ein Mediaplayer) benötigt. Statt den Code des Mediaplayers ganz oder teilweise in das eigene Projekt zu kopieren, bieten viele VCS die Möglichkeit von Subrepositories, auch Submodule genannt.

In unserem Beispiel wird das Repository des Mediaplayers als Subrepository in das Repository der Website integriert und erscheint dann als separates Verzeichnis im Verzeichnisbaum. Das bedeutet, dass die Codebasis des Mediaplayers vollständig verfügbar ist, aber unabhängig bleibt und bei Bedarf sogar aus dem ursprünglichen Repository des Mediaplayers aktualisiert werden kann.

Dieses Feature erweist sich bei der Organisation komplexer Projekte mit zahlreichen Abhängigkeiten oder der Integration von Bibliotheken und Frameworks von Drittanbietern in eine Codebasis als überaus hilfreich. Submodule verbessern die Projektorganisation und erleichtern die Zusammenarbeit, indem sie Entwicklern die Möglichkeit geben, effizient mit dem Code verschiedener (Teil-)Projekte zu arbeiten.

Jeder Mitwirkende an einem Projekt beginnt mit der Erstellung einer Identität, die in der Regel mit seiner eindeutigen E-Mail-Adresse verknüpft ist. Cloud-basierte Systeme verwalten Identitäten über Konten, wie es auch Social Media Sites und andere Organisationen tun.

Neue Entwickler durchlaufen eine Prozedur wie die folgende, wenn sie ein SCM-System verwenden:

Die Projektleiter entscheiden, wem sie vertrauen und Zugang zum Repository gewähren. Senior Developer haben die wichtige Aufgabe zu entscheiden, wann die von anderen Mitwirkenden eingereichten Änderungen in den Hauptzweig des Repositorys aufgenommen werden.

In Cloud-basierten Systemen kann der Owner eines Projekts den Zugang zu einem Repository auch dadurch steuern, dass er dessen Sichtbarkeit auf “öffentlich” oder “privat” einstellt. Öffentliche Repositories gewähren jedermann Lesezugriff über das Internet. Private Repositories hingegen beschränken den Zugriff auf den Eigentümer, auf Personen, für die der Eigentümer den Zugriff ausdrücklich freigegeben hat, und im Falle von Organisations-Repositories auf bestimmte Mitglieder der Organisation.

Stellen Sie sich ein Team von Entwicklern vor, die an einer E-Commerce-Website arbeiten. Sie beschließen, eine neue Funktion hinzuzufügen, über die Kunden ihre Bestellungen nachverfolgen können. Um diese Funktion zu implementieren, erstellen sie einen Feature Branch mit einem Namen wie order-tracking; darin nehmen sie die notwendigen Änderungen im Code vor, ohne die Hauptcodebasis zu ändern. Sobald die Funktion fertiggestellt und getestet ist, fügen sie diesen Branch in den Hauptentwicklungszweig (Development Branch) für weitere Integration und Tests ein.

Der Hauptentwicklungszweig dient als zentraler Knotenpunkt, in dem alle neuen Funktionen zum Testen zusammengeführt werden. Wenn beispielsweise mehrere Entwickler gleichzeitig an verschiedenen Funktionen arbeiten, können sie ihre Feature Branches mit dem Development Branch zusammenführen, um sicherzustellen, dass alles reibungslos funktioniert. Dieser Integrationsprozess hilft dabei, etwaige Konflikte oder Kompatibilitätsprobleme frühzeitig zu erkennen und zu beheben.

Wenn es an der Zeit ist, eine neue Version der E-Commerce-Website freizugeben, erstellt das Team aus dem Development Branch einen Release Branch, beispielsweise v2.0. Sie konzentrieren sich darauf, die Codebasis zu stabilisieren, letzte Fehler zu beheben und gründliche Tests durchzuführen, um eine reibungslose Veröffentlichung zu gewährleisten. Ist die Freigabe erteilt, wird der Code aus dem Release Branch in die produktiven Systeme ausgeliefert (Deploy), und der Zyklus beginnt von neuem.

Einige der bekanntesten Versionskontrollsysteme sind Git, Subversion (auch bekannt als SVN) und CVS. All diese Systeme sind Open Source.

Git ist ein verteiltes Versionskontrollsystem, das in der Softwareentwicklung und anderen Bereichen weit verbreitet ist. Bei der Arbeit mit Git hat jeder Entwickler eine vollständige Kopie der Codebasis auf seinem Computer.

Der dezentrale Ansatz ermöglicht es den Entwicklern, offline zu arbeiten und nahtlos zusammenzuarbeiten, ohne auf einen zentralen Server angewiesen zu sein. Das heißt, sie können unabhängig voneinander an verschiedenen Funktionen oder Fehlerbehebungen arbeiten sowie Änderungen nahtlos zusammenführen oder Updates untereinander austauschen, selbst wenn der zentrale Server offline geht.

Erinnern Sie sich an die Entwicklung des Linux-Kernels, der ursprünglich auf ein zentralisiertes Versionskontrollsystem namens BitKeeper angewiesen war. Als der kostenlose Status von BitKeeper aufgehoben wurde, entwickelten Linus Torvalds und die Linux Community Git als verteilte Alternative. Diese Entscheidung machte eine nicht-lineare und hoch effiziente Entwicklung großer Projekte wie des Linux-Kernels erst möglich. Der Erfolg von Git für den Linux-Kernel — ein extrem komplexes Projekt mit Tausenden von Entwicklern und unzähligen Branches — zeigt die Leistungsfähigkeit und Skalierbarkeit des Systems.

Die meisten Softwareentwickler setzen heute auf Git, und auch beliebte SaaS-Angebote bauen darauf auf.

Git behandelt Konflikte, indem es dem Entwickler eine Datei mit beiden Versionen der geänderten Zeile zeigt und deutlich markiert, aus welcher Version der Datei die Zeilen stammen. Der Entwickler muss entscheiden, wie er den Konflikt auflöst und eine kohärente Version der Datei eincheckt.

Subversion (SVN) war vor Git das wahrscheinlich populärste SCM-System. Im Gegensatz zu Git ist Subversion zentralisiert: Die Versionsgeschichte liegt auf einem zentralen Server. Die Entwickler verbinden sich mit diesem Server, um Änderungen vorzunehmen, wodurch sichergestellt wird, dass jeder mit der neuesten Version der Codebasis arbeitet.

Angenommen Sie sind Teil eines Teams, das an einem Projekt mit Subversion arbeitet. Jedes Mal, wenn Sie Änderungen an der Codebasis vornehmen müssen, stellen Sie eine Verbindung zum zentralen SVN-Server her, um eine Arbeitskopie des Codes auszuchecken. So stellen Sie sicher, dass Sie mit der aktuellsten Version des Projekts arbeiten. Nachdem Sie Ihre Änderungen vorgenommen haben, übertragen Sie sie zurück auf den Server und aktualisieren das zentrale Repository mit Ihren Änderungen. Dieser zentralisierte Arbeitsablauf trägt dazu bei, die Konsistenz des Projekts zu wahren.

Vor Subversion war CVS ein sehr beliebtes, zentralisiertes Versionskontrollsystem, das aber Designprobleme hatte, die zur Entwicklung von Subversion als Alternative führten.