Verteilte Versionskontrollsysteme (Distributed Version Control System, DVCS) sind in der Software-Entwicklung ein großer Schritt vorwärts. Aber in der Regel können Teams nicht einfach per Knopfdruck umsteigen. Die Codebasis der Produkte und Bibliotheken muss von zentralisierten Versionskontrollsystemen (zumeist SVN) auf DVCS migriert werden – und diese Migrationen sind häufig richtig groß.
Warum DVCS?
Die Migration einer großen Codebasis ist nicht umsonst zu haben. Die erste Frage, die sich sowohl das Entwicklungsteam als auch andere Beteiligte wie Manager und Stakeholder stellen müssen, lautet deshalb: Was bringt eine verteilte Versionskontrolle und warum ist die Migration die Kosten wert?
In vielen Unternehmen, Teams und Projekten kommt SVN erfolgreich zum Einsatz. Wenn Subversion die eigenen Anforderungen an eine Versionskontrolle jahrelang erfüllt hat – warum dann wechseln? Diese Frage ist hier aber gar nicht die richtige. Sie müsste vielmehr lauten: Inwiefern kann ein verteiltes Versionskontrollsystem das, was wir heute tun, besser machen?
Git ist für diverse Vorteile bekannt. Für Entwickler, die mit Code arbeiten, ist Git schneller. Es erlaubt fortgeschrittene Workflows mit Branches, Forks und Pull-Requests. Theoretisch sind diese Workflows mit SVN ebenfalls möglich, aber das Mergen ist in SVN im Vergleich zu Git so kompliziert, dass niemand sie umsetzt. Teams, die von SVN zu Git migrieren, erkennen das einfache Branching und Merging schnell als große Stärke. Tatsächlich lässt sich der Standard-SVN-Workflow mit Git besser abbilden als mit SVN!
Wie entwickeln Teams Software?
Was bedeutet das? Hier ist es sinnvoll, sich anzusehen, wie Software normalerweise entwickelt wird. Die meisten Teams haben zumindest eine ausgelieferte Version der Software, die in der Regel als Stable-Branch bezeichnet wird. Wartungsaufgaben und Bugfixes werden im Stable-Branch durchgeführt, während neue Features in einem Development-Branch entwickelt werden. (Je nach Versionskontrolle heißt dieser trunk, master oder default.)
Werden Bugfixes in den Stable-Branch commitet, müssen sie auch in den Master-Branch gelangen. Doch SVN-Merges sind schmerzhaft und basieren lediglich auf der Revisionshistorie – nicht auf tatsächlichem Content. Im Endeffekt vermeiden viele Entwickler das Mergen oder sie tun es unregelmäßig und nicht als Teil der täglichen Routine. Das Ergebnis sind Software-Projekte, in denen Stable- und Development-Branches zu divergieren beginnen oder schon so stark divergieren, dass die erneute Zusammenführung richtig aufwändig ist.
Und das ist in Teams, die mit SVN arbeiten, keine Seltenheit. Es gibt Strategien, um dies zu handhaben. Beispielsweise kann man das Mergen ignorieren und die Entwickler dazu anhalten, jeden Commit individuell in die Stable- und Development-Branches hinzuzufügen, und das Qualitätssicherungsteam muss sich um die Einhaltung dieses Workflows kümmern. Aber auch das ist alles andere als schön und einfach.
Git erlöst von Schmerzen
Git als verteiltes Versionskontrollsystem erlöst Entwicklungsteams von solchen Schmerzen. Das Mergen ist so einfach, dass das Mergen des gesamten Stable-Branchs in den Development-Branch mit jedem Commit Realität wird; in vielen Git-Teams ist dies der Standard-Workflow. Und selbst den Teams, die nicht sofort mit Feature-Branches oder Forks oder Pull-Requests arbeiten wollen, bietet Git vom ersten Tag an Vorteile - Wie gesagt: Selbst der Standard-SVN-Workflow kann mit Git besser abgebildet werden als mit SVN.
Und wenn ein Team so weit in Git eingearbeitet ist, dass es das verteilte Versionskontrollsystem produktiv nutzen kann, entfalten sich die Potenziale für das ganze Unternehmen: mehr Produktivität durch weniger Komplexität beim Mergen, mehr Sicherheit, signifikant kürzere Realease-Zyklen für Produkte dank der Branches als Kernprinzip des Entwicklungs-Workflows.
Weiterführende Infos: Ihr Partner für Git und Stash
Kennen Sie Stash, Atlassians Git-Repository-Managementsystem? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.
Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.
99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten
