Close

Von SVN zu Git – Migrationsvorbereitung

In Warum Git? haben wir besprochen, wie Git deinem Team in vielerlei Hinsicht dabei helfen kann, agiler zu werden. Sobald du dich für den Wechsel entschieden hast, ist der nächste Schritt die Planung der Migration deines bestehenden Entwicklungs-Workflows zu Git.

In diesem Artikel erfährst du, welches die größten Veränderungen sind, die dich und dein Team bei einer Umstellung von SVN auf Git erwarten. Der wichtigste Grundgedanke beim Migrationsprozess ist, das Git eben nicht SVN ist. Um das volle Potenzial von Git zu nutzen, musst du dich neuen Denkweisen hinsichtlich der Versionskontrolle öffnen.


Für Administratoren


Die Einführung von Git kann je nach Teamgröße von wenigen Tagen bis zu mehreren Monaten dauern. Auf dieser Seite gehen wir auf einige der größten Bedenken ein, die Entwicklungsmanager bezüglich des Trainings ihrer Mitarbeiter in Git und der Migration von Repositorys von SVN zu Git haben.

Grundlegende Git-Befehle


Git stand einmal im Ruf, eine steile Lernkurve zu erfordern. Die Git-Maintainer haben jedoch stetig neue Verbesserungen herausgebracht. Dazu zählen sinnvolle Standardeinstellungen und Hilfenachrichten im Kontext, die den Einstieg deutlich angenehmer gestalten.

Atlassian bietet eine umfangreiche Reihe an Git-Tutorials im individuellen Lerntempo sowie Webinare und Live-Trainings. Alle zusammen sollten deinem Team jede Trainingsoption bieten, die für den Einstieg in Git benötigt wird. Im Folgenden haben wir einige grundlegende Git-Befehle für den Einstieg aufgelistet:

Datenbanken
Zugehöriges Material

Verschieben eines vollständigen Git-Repositorys

Bitbucket-Logo
Lösung anzeigen

Git kennenlernen mit Bitbucket Cloud

Git-Aufgabe

Hinweis

Git-Befehle

Git mitteilen, wer du bist

Hinweis

Konfiguriere den Autorenname und die E-Mail-Adresse für deine Commits. Beachte dass, Git gewisse Zeichen (z. B. abschließende Punkte) vom user.name (Benutzernamen) entfernt.

Git-Befehle

git config --global user.name "Sam Smith"git config --global user.email sam@example.com

Erstellen eines neuen lokalen Repositorys

Notes

 

Git-Befehle

git init

Auschecken eines Repositorys

Hinweis

Erstelle eine Arbeitskopie eines lokalen Repositorys:

Git-Befehle

git clone /path/to/repository

 

Hinweis

Für einen Remote-Server verwendest du:

Git-Befehle

git clone username@host:/path/to/repository

Hinzufügen von Dateien

Hinweis

Füge eine oder mehrere Datei(en) zur Staging-Umgebung (Index) hinzu:

Git-Befehle

git add *

Durchführen von Commits

Hinweis

Committe Änderungen an den Head (aber noch nicht an das Remote-Repository):

Git-Befehle

git commit -m "Commit-Nachricht"

 

Hinweis

Committe Dateien, die du mit "git add" hinzugefügt hast, und auch Dateien, die du seither geändert hast:

Git-Befehle

git commit -a

Durchführen von Pushes

Hinweis

Sende Änderungen an den Main-Branch deines Remote-Repositorys:

Git-Befehle

git push origin main

Status

Hinweis

Lass dir die Dateien anzeigen, die du geändert hast und die du noch hinzufügen oder committen musst:

Git-Befehle

git status

Verbinden mit einem Remote-Repository

Hinweis

Wenn du dein lokales Repository noch nicht mit einem Remote-Server verbunden hast, füge den Server hinzu, um Pushes zu ihm durchführen zu können:

Git-Befehle

git remote add origin

 

Hinweis

Lass dir eine Liste aller aktuell konfigurierten Remote-Repositorys anzeigen:

Git-Befehle

git remote -v

Branches

Hinweis

Erstelle einen neuen Branch und wechsle zu ihm:

Git-Befehle

git checkout -b

 

Hinweis

Wechsle von einem Branch zu einem anderen:

Git-Befehle

git checkout

 

Hinweis

Lass dir alle Branches in deinem Repository auflisten, mit der Angabe, in welchem Branch du dich aktuell befindest:

Git-Befehle

git branch

 

Hinweis

Lösche den Feature Branch:

Git-Befehle

git branch -d

 

Hinweis

Pushe den Branch in dein Remote-Repository, damit er auch von anderen Personen verwendet werden kann:

Git-Befehle

git push origin

 

Hinweis

Pushe alle Branches in dein Remote-Repository:

Git-Befehle

git push --all origin

 

Hinweis

Lösche einen Branch in deinem Remote-Repository:

Git-Befehle

git push origin :

Updates vom Remote-Repository

Hinweis

Rufe Änderungen vom Remote-Server ab und führe einen Merge in dein Arbeitsverzeichnis durch:

Git-Befehle

git pull

 

Hinweis

Merge einen anderen Branch in deinen aktiven Branch:

Git-Befehle

git merge

 

Hinweis

Lass dir alle Merge-Konflikte anzeigen: Lass dir die Konflikte mit der Basisdatei anzeigen: Sieh dir vor dem Merge eine Vorschau der Änderungen an:

Git-Befehle

git diff
git diff --base
git diff

 

Hinweis

Nachdem du alle Konflikte manuell gelöst hast, markierst du die geänderte Datei:

Git-Befehle

git add

Tags

Hinweis

Du kannst mithilfe von Tags ein bedeutendes Changeset wie z. B. einen Release kennzeichnen.

Git-Befehle

git tag 1.0.0

 

Hinweis

Die CommitId besteht aus den bis zu zehn ersten Zeichen der Changeset-ID. Sie muss eindeutig sein. Du erhältst die ID über:

Git-Befehle

git log

 

Hinweis

Pushe alle Tags ins Remote-Repository:

Git-Befehle

git push --tags origin

Rückgängigmachen lokaler Änderungen

Hinweis

Wenn dir ein Fehler unterlaufen ist, kannst du die Änderungen in deinem Arbeitsbaum mit dem letzten Inhalt des Head ersetzen: Änderungen, die bereits dem Index hinzugefügt wurden sowie neue Dateien bleiben erhalten.

Git-Befehle

git checkout --

 

Hinweis

Um stattdessen alle deine lokalen Änderungen und Commits zu verwerfen, den neuesten Verlauf vom Server abzurufen und deinen lokalen Main-Branch darauf zu verweisen, gehst du folgendermaßen vor:

Git-Befehle

git fetch origingit reset --hard origin/main

Suchen

Hinweis

Suche im Arbeitsverzeichnis nach foo():

Git-Befehle

git grep "foo()"

Git-Migrationstools


Es gibt verschiedene Tools, um die Migration bestehender Projekte von SVN zu Git zu unterstützen, aber bevor du dich für welche entscheidest, solltest du dir darüber im Klaren sein, auf welche Weise du deinen Code migrieren möchtest. Du hast die folgenden Optionen:

  • Migrieren der gesamten Codebasis und keine weitere Verwendung von SVN
  • Migriere keine bestehenden Projekte in Git, aber beginne alle neuen Projekte in Git.
  • Migrieren einiger Projekte zu Git und Weiterverwenden von SVN für die übrigen Projekte
  • Verwende SVN und Git gleichzeitig für dieselben Projekte.

Ein vollständiger Wechsel zu Git sorgt für einen weniger komplexen Workflow und ist deshalb die bevorzugte Option. Dies ist in größeren Unternehmen mit Dutzenden Entwicklungsteams und möglicherweise Hunderten Projekten jedoch nicht immer möglich. Unter solchen Gegebenheiten ist ein hybrider Ansatz sicherer.

Die Auswahl deiner Migrationstools hängt stark davon ab, für welche der obigen Strategien du dich entscheidest. Einige der am häufigsten genutzten Tools für die Migration von SVN zu Git werden unten vorgestellt.

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".

Für Entwickler


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.

Fazit


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.


Diesen Artikel teilen

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Mitarbeiter arbeiten mit unzähligen Tools zusammen

Bitbucket-Blog

Abbildung: DevOps

DevOps-Lernpfad

Demo Den: Feature-Demos mit Atlassian-Experten

So funktioniert Bitbucket Cloud mit Atlassian Open DevOps

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up