Von SVN zu Git – Migrationsvorbereitung

Migrationsskripte von Atlassian

Wenn du schlagartig auf Git umstellen möchtest, sind die Migrationsskripte von Atlassian eine gute Wahl. Diese Skripte bieten alle Tools, die du zur zuverlässigen Konvertierung deiner bestehenden SVN-Repositorys in Git-Repositorys benötigst. Durch den daraus resultierenden nativen Git-Verlauf wird vermieden, dass du nach dem Konvertierungsprozess mit Interoperabilitätsproblemen zwischen SVN und Git zu kämpfen hast.

Wir stellen dir eine umfassende technische Erläuterung zur Verwendung dieser Skripte zum Konvertieren deiner gesamten Codebasis in eine Sammlung von Git-Repositorys bereit. In diesen Erläuterungen erfährst du alles von der Extrahierung von SVN-Autoreninformationen bis zur Neuorganisation von nicht-standardmäßigen SVN-Repository-Strukturen.

Plug-in SVN Mirror for Stash (jetzt Bitbucket)

SVN Mirror for StashSVN Mirror for Stash ist ein Bitbucket-Plug-in, mit dessen Hilfe du problemlos eine hybride Codebasis pflegen kannst, die mit SVN und Git kompatibel ist. Im Gegensatz zu den Migrationsskripten von Atlassian kannst du mit SVN Mirror for Stash Git und SVN so lange du möchtest gleichzeitig für dasselbe Projekt nutzen.

Diese Kompromisslösung ist eine gute Option für größere Unternehmen. Sie ermöglicht die inkrementelle Einführung von Git, da die verschiedenen Teams ihre Workflows zu dem Zeitpunkt migrieren können, der für sie am besten passt.

Was ist Git-SVN?

Das "git-svn"-Tool ist eine Schnittstelle zwischen einem lokalen Git-Repository und einem SVN-Remote-Repository. "Git-svn" ermöglicht Entwicklern lokal in Git Code zu schreiben und Commits zu erstellen und dann die Commits in ein zentrales SVN-Repository mit Verhalten im SVN-Commit-Stil zu pushen. Dies sollte nur eine zeitlich begrenzte Übergangslösung sein, ist aber hilfreich, wenn über einen Wechsel von SVN zu Git noch diskutiert wird.

Git svn ist eine gute Option, wenn du dir noch nicht sicher bist, ob ein Wechsel zu Git für dich in Frage kommt, und du deinen Entwicklern die Möglichkeit geben möchtest, Git-Befehle kennenzulernen, ohne eine vollständige Migration durchzuführen. Es eignet sich auch hervorragend für die Trainingsphase – statt eines abrupten Übergangs, kann dein Team sich langsam an die Git-Befehle gewöhnen, bevor es sich Gedanken über Zusammenarbeits-Workflows machen muss.

Beachte, dass git svn nur eine Übergangsphase in deinem Migrationsprozess sein darf. Da du dabei weiterhin auf SVN als Backend angewiesen bist, kannst du damit Git-Features wie Branching oder erweiterte Zusammenarbeits-Workflows nicht voll ausnutzen.

Einführungsstrategien

Die Migration deiner Codebasis ist nur ein Aspekt bei der Einführung von Git. Du musst außerdem darüber nachdenken, wie du die Mitarbeiter, die hinter der Codebasis stehen, an Git heranführst. Externe Berater, interne Git-Experten und Pilotteams sind drei Hauptstrategien für den Wechsel deines Entwicklerteams zu Git.

Externe Git-Berater

Git-Berater können gegen eine geringe Gebühr den Migrationsprozess im Wesentlichen für dich übernehmen. Dies hat den Vorteil, dass ein Git-Workflow erstellt wird, der perfekt auf dein Team passt, und du keine Zeit darin investieren musst, diesen selbst zu gestalten. Außerdem hast du auf diese Weise Zugang zu Experten für Git-Trainings in der Kennenlernphase deines Teams. Atlassian Partner sind Profis in der Migration von SVN zu Git und können dir einen Git-Berater vermitteln.

Andererseits ist die eigenständige Konzipierung und Implementierung eines Git-Workflows eine gute Methode für das Team, ihren neuen Entwicklungsprozess im Detail verstehen zu lernen. So bleibt das Team nicht im Regen stehen, wenn der Berater nicht mehr vor Ort ist.

Interne Git-Experten

Ein Git-Experte ist ein Entwickler in deinem Unternehmen, der sich auf den Umstieg auf Git freut. Der Einsatz von Git-Experten ist eine gute Option für Unternehmen mit einer starken Entwicklerkultur und eifrigen Programmieren, die bei der Einführung gerne zu den Pionieren gehören. Die Idee dahinter ist, dass ein interner Entwickler zum Git-Experten wird und einen für das Unternehmen maßgeschneiderten Git-Workflow konzipiert sowie als interner Berater fungieren kann, wenn das übrige Team auf Git umstellt.

Im Vergleich zu einem externen Berater hat dies den Vorteil, dass du deine Git-Kenntnisse im eigenen Haus behältst. Dies bringt jedoch einen hohen Zeitaufwand für das Training dieses Git-Experten und das Risiko, den falschen Git-Workflow auszuwählen oder ihn nicht korrekt zu implementieren, mit sich.

Pilotteams

Die dritte Option für die Umstellung auf Git ist ein Testlauf in einem Pilotteam. Dies funktioniert am besten in kleinen Teams, die an einem relativ isolierten Projekt arbeiten. Noch besser funktioniert diese Methode, wenn du im Pilotteam eine Kombination externer Berater und interner Git-Experten einsetzt. So kann eigentlich nichts mehr schiefgehen.

Dies hat den Vorteil, dass das gesamte Team dahinterstehen muss, wodurch auch das Risiko der Auswahl eines falschen Workflows sinkt, da das ganze Team sich an der Erarbeitung des neuen Entwicklungsprozesses beteiligt. Mit anderen Worten, dies sorgt dafür, dass auch kleine Unzulänglichkeiten schneller bemerkt werden, als wenn ein Berater oder interner Experte den neuen Workflow alleine entwirft.

Andererseits erfordert der Einsatz eines Pilotteams mehr anfängliche Zeit für Training und Aufbau: Anstatt dass ein Entwickler einen neuen Workflow entwickelt, ist ein ganzes Team für einen gewissen Zeitraum potenziell weniger produktiv, während es sich an den neuen Workflow gewöhnt. Die langfristigen Vorteile sind jedoch die kurzfristigen Wehen mehr als wert.

Sicherheit und Zugriffsrechte

Zugriffskontrolle ist ein Aspekt von Git, bei dem du das Management deiner Codebasis grundlegend überdenken musst.

In SVN speicherst du normalerweise deine gesamte Codebasis in einem einzigen zentralen Repository und beschränkst den Zugriff verschiedener Teams oder Einzelpersonen für jeden Ordner. In Git ist dies nicht möglich: Die Entwickler müssen für ihre Arbeit das gesamte Repository abrufen. Normalerweise kann das Repository nicht wie in SVN in Teilen abgerufen werden. Zugriffsrechte werden immer nur für ganze Git-Repositorys erteilt.

Daher musst du dein großes SVN-Repository in mehrere kleine Git-Repositorys aufteilen. Wir bei Atlassian haben diese Erfahrung selbst gemacht, als unser Jira-Entwicklerteam zu Git migrierte. Alle unsere Jira-Plug-ins waren vorher in einem einzigen SVN-Repository gespeichert, nach der Migration jedoch in einem jeweils eigenen Repository.

Git wurde schließlich zur sicheren Integration von Code konzipiert, der von Tausenden unabhängiger Linux-Entwickler stammt. Deshalb bietet Git selbstverständlich Möglichkeiten zur Einrichtung jeder benötigten Art von Zugriffskontrolle. Hierfür musst du jedoch möglicherweise deinen Build-Zyklus aus einem neuen Blickwinkel betrachten.

Wenn du Bedenken bezüglich der Bewahrung von Abhängigkeiten zwischen deiner neuen Sammlung an Git-Repositorys hast, wäre möglicherweise eine Ebene über Git zum Management der Abhängigkeiten hilfreich. Eine Ebene zum Abhängigkeitsmanagement sorgt dafür, dass Build-Zeiten nicht zu lang werden, da du für ein zunehmend wachsendes Projekt Caching benötigst, um deine Build-Zeiten zu beschleunigen. Eine Liste empfohlener Abhängigkeitsmanagementtools für die verschiedensten Technologie-Stacks findest du in diesem hilfreichen Artikel: "Git und Projektabhängigkeiten".

Ein Repository für jeden Entwickler

Die größte Veränderung, an die sich die Entwickler gewöhnen müssen, ist der verteilte Ansatz von Git. Statt eines einzigen zentralen Repositorys verfügt jeder Entwickler über seine eigene Kopie des gesamten Repositorys. Dies ändert die Art und Weise der Zusammenarbeit mit deinen Programmiererkollegen radikal.

Du checkst nicht mehr ein SVN-Repository mit "svn checkout" aus und erhältst eine Arbeitskopie, sondern du klonst mit "git clone" das gesamte Git-Repository auf deinen lokalen Rechner.

Zusammenarbeit findet statt, indem Branches zwischen Repositorys mit "git push", "git fetch" oder "git pull" verschoben werden. Das Teilen geschieht in Git üblicherweise auf Branch-Ebene, kann aber auch ähnlich wie bei SVN auf Commit-Ebene ablaufen. In Git repräsentiert ein Commit jedoch den Status des gesamten Projekts statt nur Dateiänderungen. Da du sowohl in Git als auch in SVN Branches nutzen kannst, ist der entscheidende Unterschied hier, dass du mit Git lokal committen kannst, ohne deine Arbeit zu teilen. Auf diese Weise kannst du freier experimentieren, effektiver offline arbeiten und nahezu alle Befehle bezüglich der Versionskontrolle beschleunigen.

Dabei muss jedoch betont werden, dass ein Remote-Repository keine direkte Verbindung in das Repository von jemand anders ist. Es ist schlichtweg ein Lesezeichen, damit du nicht jedes Mal, wenn du mit einem Remote-Repository interagierst, die volle URL erneut eingeben musst. Bis zu einem expliziten Pull oder Push eines Branch in ein Remote-Repository arbeitest du in einer isolierten Umgebung.

Die andere große Umstellung für SVN-Benutzer ist das Konzept lokaler und Remote-Repositorys. Lokale Repositorys befinden sich auf deinem lokalen Rechner, alle anderen Repositorys werden als Remote-Repositorys bezeichnet. Ein Remote-Repository hat hauptsächlich die Aufgabe, dem übrigen Team Zugriff auf deinen Code zu ermöglichen. In ihm findet keine aktive Entwicklung statt. Lokale Repositorys befinden sich auf deinem lokalen Rechner und dort läuft auch deine gesamte Softwareentwicklung ab.

Keine Angst vor Branching oder Merging

In SVN wird Code committet, indem die Dateien in deiner Arbeitskopie bearbeitet und dann "svn commit" ausgeführt wird, um den Code an das zentrale Repository zu senden. Alle anderen Teammitglieder können nun mit "svn update" einen Pull dieser Änderungen in ihre eigenen Arbeitskopien durchführen. SVN-Branches werden normalerweise nur für große, lang andauernde Aspekte eines Projekts genutzt, da der Merge Gefahren birgt und ggf. das Projekt beschädigen kann.

Der grundlegende Entwicklungs-Workflow in Git unterscheidet sich hiervon deutlich. Anstatt dass du an eine einzige Entwicklungslinie (z. B. einen Trunk) gebunden bist, dreht sich alles rund um Branching und Merging.

Wenn du in Git zu arbeiten beginnst, kannst du mit "git checkout -b" einen neuen Branch erstellen und auschecken. So erhältst du einen speziellen Entwicklungszweig, um deinen Code zu schreiben, und musst dich nicht um Auswirkungen auf andere Teammitglieder kümmern. Wenn etwas unwiderruflich in die Brüche geht, kannst du den Branch mit dem Befehl "git branch -d" ganz einfach verwerfen. Wenn dir etwas gelungen ist, erstellst du eine Pull-Anfrage und bittest darum, dass dein Branch in den Main-Branch gemergt wird.

Potenzielle Git-Workflows

Bei der Auswahl eines Git-Workflow musst du unbedingt die Anforderungen deines Teams berücksichtigen. Ein einfacher Workflow kann die Entwicklungsgeschwindigkeit und Flexibilität erhöhen, während ein komplexerer Workflow für mehr Konsistenz und Kontrolle bei den WIP-Aufgaben sorgt. Du kannst die unten aufgeführten allgemeinen Ansätze an deine Anforderungen und die der verschiedenen Rollen in deinem Team anpassen und entsprechend kombinieren. Ein Entwickler des Kernteams arbeitet z. B. in Feature Branches, ein Auftragnehmer dagegen in einer Fork.

• Ein zentralisierter Workflow ist den üblichen SVN-Prozessen am ähnlichsten und somit eine gute Option für den Einstieg.
• Aufbauend darauf ermöglicht ein Feature Branch Workflow den Entwicklern, ihre WIP-Aufgaben isoliert und wichtige gemeinsame Branches geschützt zu halten. Feature Branches bilden außerdem die Basis für das Management von Änderungen per Pull-Requests.
• Ein Git-flow-Workflow ist eine formellere, strukturiertere Erweiterung des Feature Branching und somit eine gute Option für größere Teams mit klar definierten Release-Zyklen.
• Und zu guter Letzt solltest du über einen Forking Workflow nachdenken, wenn du maximale Isolation und Kontrolle deiner Änderungen benötigst oder viele Entwickler zu einem Repository beitragen.

Aber wenn du Git als professionelles Team wirklich optimal nutzen möchtest, solltest du den Feature Branch Workflow in Betracht ziehen. Dies ist ein echter verteilter Workflow mit höchster Sicherheit, enormer Skalierbarkeit und grundlegender Agilität.

Die Umstellung auf Git kann für dein Team eine einschüchternde Aufgabe sein, muss es aber nicht. In diesem Artikel haben wir einige häufig genutzte Optionen für die Migration einer bestehenden Codebasis, den Rollout von Git in deinen Entwicklerteams und den Umgang mit Sicherheit und Zugriffsrechten vorgestellt. Darüber hinaus haben wir die größten Herausforderungen, die deine Entwickler während des Migrationsprozesses erwarten angesprochen.

Nun verfügst du hoffentlich über eine solide Grundlage zur Einführung einer verteilten Entwicklung in deinem Unternehmen – unabhängig von dessen Größe oder derzeitigen Entwicklungsverfahren.