Posted on Leave a comment

Versionsverwaltung

Versionsverwaltung

Als Versionskontrolle oder Versionsverwaltung bezeichnet man das Vorgehen, Änderungen an Dokumenten und Dateien kontinuierlich zu erfassen. Dazu werden sogenannte Version Control Systems (VCS) genutzt. Die Versionen der Dateien werden meist mit einem Zeitstempel und einer Benutzerkennung gespeichert, sodass sie später wiederhergestellt beziehungsweise Änderungsverläufe chronologisch nachvollzogen werden können. In der Softwareentwicklung wird Versionskontrolle typischerweise dazu verwendet, Quelltexte zu verwalten. Dadurch wird sowohl eine bessere Übersicht über den gesamten Entwicklungsprozess als auch die parallele Arbeit an verschiedenen Features ermöglicht. Im Folgenden stellen wir die verschiedenen Möglichkeiten und Konzepte von Versionsverwaltung vor und erklären, wie sie mit Git umgesetzt werden.

Ziel und Vorteile von Versionskontrolle

Kollaboration ist für Softwareprojekte, egal ob privat oder für ein Unternehmen, ein wichtiger Punkt. Oft arbeiten mehrere Entwickler gleichzeitig an unterschiedlichen Features und Funktionen. Eine umfangreiche Codebasis kann dabei schnell unübersichtlich werden und manchmal ist es nicht offensichtlich, welche Änderungen vorgenommen wurden und woher manche Fehler kommen – sie können sich sogar aus dem Zusammenspiel mehrerer Änderungen ergeben.

Versionsverwaltung ermöglicht es, jede einzelne Änderung auch nach längerer Zeit nachzuvollziehen und dem entsprechenden Entwickler zuzuordnen. Insbesondere durch eine graphische Darstellung, die viele VCS bereitstellen, wird die Übersichtlichkeit so deutlich erhöht. Zudem ist es möglich, einzelne Änderungen rückgängig zu machen, auf eine komplett andere, lauffähige Version zurückzufallen und verschiedene Versionen zu kombinieren. Das gibt Sicherheit, dass fehlerhafte Änderungen keine großen Auswirkungen und Zeitkosten haben.

Unabhängig davon unterstützen VCS das Arbeiten mehrerer Entwickler an einem Projekt oder mehreren Features gleichzeitig. Dazu wird ein Repository (dt. Behälter oder Aufbewahrungsort) eingerichtet, das das Projekt enthält. Jeder Entwickler kann sich den aktuellen Stand des Repositories kopieren und daran als sogenannte Arbeitskopie Änderungen vornehmen. Die vorgenommenen Änderungen werden zu einem späteren Zeitpunkt wieder mit dem eigentlichen Repository zusammengeführt. Dabei wird auch eine Historie erstellt. Die genaue Kollaboration kann auf verschiedene Weisen realisiert werden, je nachdem, ob mit einem zentralem oder einem verteilten Repository gearbeitet wird.

Arbeit mit zentraler Versionskontrolle

Bei zentraler Versionskontrolle, wie sie mit dem Tool Subversion (SVN) möglich ist, erfolgt der Zugriff auf das Repository ähnlich wie bei einer Client-Server-Anwendung über das Netzwerk und wird über eine Rechteverwaltung geregelt. Alle Entwickler arbeiten aber gleichzeitig an demselben Repository. Daher muss die gemeinsame Arbeit nach dem Lock Modify Write-Prinzip (pessimistischer Versionsverwaltung) erfolgen. Möchte ein Benutzer eine Änderung an einer Datei durchführen, muss er die Datei sperren und anschließend wieder freigeben. In dieser Zeit darf kein anderer Nutzer auf die Datei schreibend zugreifen, sodass es auch nicht zu Konflikten bei der Zusammenführung von verschiedenen Versionen kommen kann. Der Nachteil dieser Methode liegt auf der Hand: Möchten zwei Entwickler gleichzeitig eine Datei bearbeiten, geht das nicht. Stattdessen kann es sogar zu langen Wartezeiten kommen, die die Arbeit blockieren. Zudem ist die Historie des Projektes selbst durch dieses Vorgehen nur an zentraler Stelle vorhanden.

Arbeit mit verteilter Versionsverwaltung

Bei verteilter Versionsverwaltung besitzt jeder Entwickler eine eigene, lokale Kopie des Repositories. Es ist jederzeit möglich, sich eine solche Kopie des aktuellen Projektes zu erstellen. Ebenso kann jede lokale Kopie grundsätzlich jederzeit mit einer anderen verglichen werden. Die Historie liegt lokal auf den einzelnen Rechnern vor und wird schließlich zusammen mit dem Code zusammengeführt.

Anders als bei einer zentralen Verwaltung kann nun nach dem Copy Modify Merge-Prinzip, sogenannter optimistischer Versionsverwaltung, gearbeitet werden. Mehrere Nutzer bearbeiten gleichzeitig die lokalen Kopien der Dateien und führen die jeweiligen Änderungen anschließend in einem sogenannten Merge-Schritt zusammen. Das ist effizienter als eine zentrale Verwaltung, den es ermöglicht die Arbeit an mehreren Features gleichzeitig. Allerdings macht der Merge-Vorgang natürlich gegebenenfalls mehr Arbeit, obwohl viele Tools, die automatisch mergen können, zur Verfügung stehen.

Lokale Versionsverwaltung

Neben zentraler und verteilter Versionsverwaltung gibt es noch lokale Versionsverwaltung, bei der oft nur eine Datei versioniert wird. Diese Form findet weniger Anwendung in der Softwareentwicklung, dafür aber in der Verwaltung von Dokumenten und in Bürosoftware.

Versionsverwaltung mit Git

Git ist eines der bekanntesten VCS, die es aktuell gibt, und ist ein verteiltes System. Es ist kostenlos verfügbar und wurde 2005 von Linus Torvalds, dem Entwickler von Linux, implementiert. Laut Open Hub, einem Online Service zur Katalogisierung von Open Source-Projekte, verwendeten 69% der erfassten Projekte Git – weit vor Subversion auf Platz 2 mit 25%. Auch viele Unternehmen setzen mittlerweile auf Git und es gibt diverse Webseiten wie GitHub oder GitLab, auf denen man kostenlos durch Git verwaltete Repositories anlegen kann.

Die Git-Terminologie

Um mit Git zu arbeiten, sollten zuerst die wichtigsten Begriffe klar sein. Grundsätzlich dazu vorab: Als verteiltes VCS nutzt Git sogenannte Branches (dt. Zweige). Jeder Branch ist eine Kopie des Repositories und kann für die Arbeit an einem Feature unabhängig und alleinstehend verwendet werden. Die Kopie „lebt“ in einem lokalen Ordner: .git. Hier werden alle zur Versionskontrolle notwendigen Daten gespeichert. Git erlaubt es, verschiedene Branches miteinander zu vergleichen, Unterschiede festzustellen, die Branches zusammenzuführen oder zu überschreiben. Um diese Funktionen zu nutzen und den Workflow von Git zu verstehen, sind folgende Begriffe notwendig:

Die Git-Begriffe am Beispiel

Um die Menge an Begriffen besser zu verstehen, ist es hilfreich ein Beispiel zu betrachten. Nehmen wir dafür an, dass Sie auf zwei Rechnern an einem Projekt arbeiten – beispielsweise mit einem Standrechner zuhause und unterwegs mit einem Laptop. Nehmen wir der Einfachheit halber außerdem an, dass sie nicht mit Branches arbeiten, sondern direkt auf dem Master.  Sie haben also auf beiden Rechnern den Master ausgecheckt und nun einige Änderungen auf dem Laptop durchgeführt. Sie haben diese Änderungen committed und auf den Master gepusht. Nun ist der Remote-Master, also der externe Master, auf einem anderen Stand als die lokale Version auf ihrem Standrechner. Beide verweisen auf einen anderen Commit. Um den Arbeitsstand lokal zu synchronisieren, können Sie mit einem Pull-Befehl die Änderungen lokal nachladen. Nun ist der Head wieder identisch.

Hätten Sie auch auf dem Standrechner Änderungen vorgenommen, so hätten Sie nicht einfach das Remote-Repository pullen können. Stattdessen hätten Sie die lokalen Änderungen zumindest erst committen müssen, sodass Git bereits weiß, welche Änderungen Sie tatsächlich dem Repository hinzufügen möchten. Sie können diese Änderungen allerdings nicht pushen, solange der Origin des Projektes bereits über Commits verfügt, die lokal nicht vorliegen. Das heißt, nachdem Sie die lokalen Änderungen committed haben, müssen Sie erst einen Pull-Befehl durchführen. Das ist nur möglich, wenn alle Änderungen committed wurden. Lassen sich alle Änderungen automatisch zusammenführen, können Sie anschließend Ihre eigenen Änderungen pushen. Remote liegen dann alle Änderungen von Ihrem Laptop und Standrechner vor. Kommt es allerdings zu einem Konflikt, beispielsweise weil Sie verschiedene Änderungen in der gleichen Zeile vorgenommen haben, müssen Sie diese Konflikte zuerst lösen. Anschließend committen Sie auch diese Anpassung des Codes und können dann den Push-Befehl ausführen. Dieser Vorgang stellt sicher, dass schlussendlich jeder Commit auf dem vorherigen aufbaut, keine Änderungen verloren gehen oder fälschlich überschrieben werden und eine nachvollziehbare Commit-Historie entsteht.

Falls Ihnen diese kurze Einführung zu den Begrifflichkeiten etwas zu knapp war: In unserem nächsten Blogartikel werden wir unser Tic Tac Toe in C# Projekt mittels Github verwalten.

Zusammenfassung

Versionsverwaltung, also das Speichern von Änderungen an Dokumenten und Dateien, bringt viele Vorteile vor allem für die Softwareentwicklung: Zum einen kann Versionsverwaltung in komplexen Projekten Übersichtlichkeit gewährleisten, zum anderen schafft sie Sicherheit, indem jederzeit eine bestimmte Version wiederhergestellt werden kann. Dazu wird ein Repository erstellt, in dem der Projektcode liegt, und an dem gemeinsam durch mehrere Entwickler gearbeitet werden kann. Insbesondere bei verteilter Versionskontrolle können sogar mehrere Entwickler an verschiedenen Features und Aufgaben arbeiten, ohne sich in die Quere zu kommen. Dazu kopiert sich jeder Entwickler das Repository lokal und modifiziert die Dateien entsprechend. Ist er fertig, werden die Dateien durch einen Merge zusammengeführt. Viele Version Control Systems (VCS) führen diesen Vorgang soweit es möglich ist automatisch durch. Das am weitesteten verbreitete VCS ist Git. Git wie auch andere VCS ist sehr mächtig, indem es nicht nur automatische Merges unterstützt, sondern auch das manuelle Rückgängigmachen und Auswählen einzelner Änderungen ermöglicht.

Ähnliche Produkte

Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.