Migration von Subversion zu Git: Das Git-Repository teilen

Der Umstieg von Subversion auf eine Git-basierte verteilte Versionskontrolle ist nicht so komplex, wie viele Entwicklungsteams annehmen. Der Prozess lässt sich in fünf aufeinanderfolgende Schritte aufteilen, die der Migration Struktur geben. Nach der Vorbereitung des lokalen Rechners eines Migrationsleiters, der Konvertierung des SVN-Repositorys in ein lokales Git-Repository und der Synchronisation des lokalen Git-Repositorys geht es nun darum, wie das neue Repo mit dem Rest des Teams geteilt werden kann.

In SVN teilt ein Entwickler seine Beiträge, indem er Änderungen von einer Working Copy auf seinem lokalen Rechner in ein zentrales Repository pusht. Dann ziehen andere Entwickler diese Aktualisierungen vom zentralen Repo in ihre eigenen lokalen Working Copies.

Der Kollaborations-Workflow mit Git unterscheidet sich davon fundamental. Statt zwischen Working Copies und dem zentralen Repository zu differenzieren, gibt Git jedem Entwickler seine eigene lokale Kopie des gesamten Repositorys. Änderungen werden in dieses lokale Repo committet statt in ein zentrales. Um Updates mit anderen Entwicklern zu teilen, müssen diese lokalen Änderungen in eine öffentliche Git-Repository auf einem Server gepusht werden. Dann können die anderen Entwickler die neuen Commits aus der öffentlichen Repo in ihre eigenen lokalen Repositories ziehen.

GIT SVN 0

Dass jeder Entwickler sein eigenes vollständige Repository hat, ist das Herzstück der verteilten Versionskontrolle, und dies eröffnet eine breite Palette an potenziellen Workflows.

Bis hierhin hat das Team nur mit einem lokalen Git-Repository gearbeitet. Nun soll dieses lokale Repo in ein öffentliches Repository gepusht werden, die in diesem Beispiel unkompliziert in Bitbucket gehostet wird. Das Teilen von Git-Repositories während der Migration erlaubt es dem Team, mit Git-Befehlen zu experimentieren, ohne dass die aktive SVN-Entwicklung davon tangiert wird. Bis das Team bereit für den Wechsel ist, ist es wichtig, dass es sich bei den geteilten Git-Repositories um Read-only-Repos handelt. Die aktive Entwicklung sollte weiterhin in das Original-SVN-Repo committet werden.

Bitbucket-Account anlegen und Bitbucket-Repo erzeugen

Wenn der Migrationsleiter noch keinen Bitbucket-Account hat, sollte er sich nun einen anlegen. Anschließend muss er ein Bitbucket-Repository erzeugen. Dafür bietet Bitbucket einen bequemen Button.

SVN-Git-Migration Teilen 1

Im anschließenden Formular muss das Repo mit Namen und Beschreibung versehen werden. Ist das Projekt privat, sollte die Option Access Level gewählt werden, damit designierte Entwickler es später klonen können. Für dieses Beispiel ist es zudem erforderlich, private Forks zu erlauben. Natürlich muss als Repository-Typ Git definiert sein. Im Language-Feld wählt der Migrationsleiter schließlich die Programmiersprache des Projekts.

SVN-Git-Migration Teilen 2

Nach dem Klick auf den Create Repository-Button ist das Repo aufgesetzt und es erscheint ein Bildschirm mit weiteren Schritten und hilfreichen Befehlen, um ein bestehendes Projekt zu importieren, die wir nun Schritt für Schritt durchgehen.

Eine origin-Remote-Verbindung aufsetzen

Um das Pushen von Commits vom lokalen Git-Repo in das Bitbucket-Repository zu erleichtern, sollte die URL des Bitbucket-Repositorys als Remote-Verbindung abgebildet werden. Eine Remote-Verbindung ist einfach eine praktische Abkürzung der URL. Technisch gesehen, kann das jede beliebige Abkürzung sein; wenn das Remote-Repository aber als offizielle Code-Basis des Projekts dient, wird für dieses normalerweise origin genutzt. Folgender Befehl ist erforderlich, um im lokalen Git-Repository das neue Bitbucket-Repo als origin-Remote-Verbindung hinzuzufügen:

git remote add origin https://<user>@bitbucket.org/<user>/<repo>.git

<user> muss durch den Bitbucket-Nutzernamen ersetzt werden, <repo> durch den Namen des Bitbucket-Repositorys. Es müsste auch möglich sein, die komplette URL aus der Bitbucket-Weboberfläche zu kopieren und hier einzusetzen.

GIT SVN Teilen 1

Nachdem der Befehl ausgeführt ist, kann origin in anderen Git-Kommandos verwendet werden.

Das lokale Repository nach Bitbucket pushen

Dann muss der Migrationsleiter das Bitbucket-Repo mit den Inhalten des lokalen Repositorys befüllen. Dieses Pushen wird durch den folgenden Befehl angestoßen:

git push -u origin --all

Die Option -u sagt Git, dass die Upstream-Branches getrackt werden sollen. Das versetzt Git in die Lage zu sagen, ob die Commit-History des Remote-Repositorys hinter der History des lokalen hinterher hängt oder ihm voraus ist. Die Option --all pusht alle lokalen Branches in das Remote-Repository.

Außerdem müssen die lokalen Tags in das Bitbucket-Repository gepusht werden:

git push --tags

Git SVN Teilen 2

Das Bitbucket-Repository ist damit quasi ein Klon des lokalen Repositorys. Über die Bitbucket-Oberfläche lässt sich die gesamte Commit-History aller Branches einsehen.

Das Repository mit dem Team teilen

Nun muss die URL des Bitbucket-Repositorys mit allen Entwicklern geteilt werden, die Zugriff brauchen. Sie lässt sich in Bitbucket von der Homepage der Repo direkt kopieren.

SVN-Git-Migration 5

Bei einem privaten Repo muss der Migrationsleiter den Teammitgliedern über das Administrations-Tab Zugriff gewähren; dort findet sich die Nutzer- und Gruppenverwaltung.

SVN-Git-Migration 6

Bitbucket bietet alternativ eine native Einladungsfunktion, mit der andere Entwickler eingeladen werden können, das Repository zu forken. Die so eingeladenen User erhalten automatisch Zugriff auf das Repo.

Wenn sie die URL des Repositorys haben, können die anderen Entwickler es mit git clone auf ihre lokalen Maschinen kopieren und mit der Arbeit an dem Projekt beginnen. Wenn ein anderer Entwickler auf seiner lokalen Maschine zum Beispiel den folgenden Befehl ausgeführt hat, findet er ein neues Git-Repository, das das Projekt enthält, im Verzeichnis <destination>:

git clone https://<user>@bitbucket.org/<user>/<project>.git <destination>

Weiterhin zu SVN committen, nicht zu Git

Damit sollte es den Entwicklern möglich sein, das lokale Projekt ins Remote-Repository zu pushen, und das Team kann dieses Remote-Repository nun nutzen, um das Projekt auf lokale Maschinen zu klonen. Das sind die nötigen Werkzeuge, um mit der Zusammenarbeit via Git zu beginnen. Allerdings sollte das Team Änderungen solange in das SVN-Repo pushen, bis alle bereit für den Umstieg sind.

Die einzigen Änderungen am Git-Repo sollten vom Original-SVN-Repsoitory ausgehen und dem schon beschriebenen Synchronisationsprozess folgen. Sowohl die lokalen Git-Repos als auch das Remote-Repository sind "read-only". Die Entwickler können mit ihnen experimentieren und sie nach und nach in den Build-Prozess integrieren, aber permanente Änderungen sollten in diesem Stadium noch nicht mit Git committet werden.

Git SVN Teilen 3

Zusammenfassung

In diesem Schritt hat der Migrationsleiter ein Bitbucket-Repository aufgesetzt, um das konvertierte Git-Repo mit seinem Team zu teilen. Damit stehen alle Tools zur Verfügung, um jeden beliebigen Git-Workflow zu implementieren.

Es kann sinnvoll sein, das Git-Repo zunächst weiter mit dem SVN-Repository zu synchronisieren und die daraus resultierenden Git-Commits via Bitbucket zu teilen, bis alle Entwickler sicher mit Git arbeiten können. Ist das der Fall, wird der Migrationsprozess abgeschlossen, indem der Migrationsleiter das SVN-Repository in den Ruhestand schickt. Das ist Thema des kommenden abschließenden Artikels dieser Reihe.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash von Atlassian? 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.

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