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:

Git-Aufgabe Hinweis Git-Befehle
Git mitteilen, wer du bist 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 config --global user.name "Sam Smith"
git config --global user.email sam@example.com
Erstellen eines neuen lokalen Repositorys   git init
Auschecken eines Repositorys Erstelle eine Arbeitskopie eines lokalen Repositorys: git clone /path/to/repository
  Für einen Remote-Server verwendest du: git clone username@host:/path/to/repository
Hinzufügen von Dateien Füge eine oder mehrere Datei(en) zur Staging-Umgebung (Index) hinzu: git add <filename>git add *
Durchführen von Commits Committe Änderungen an den Head (aber noch nicht an das Remote-Repository): git commit -m "Commit-Nachricht"
  Committe Dateien, die du mit "git add" hinzugefügt hast, und auch Dateien, die du seither geändert hast: git commit -a
Durchführen von Pushes Sende Änderungen an den Master Branch deines Remote-Repositorys: git push origin master
Status Lass dir die Dateien anzeigen, die du geändert hast und die du noch hinzufügen oder committen musst: git status
Verbinden mit einem Remote-Repository 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 remote add origin <server>
  Lass dir eine Liste aller aktuell konfigurierten Remote-Repositorys anzeigen: git remote -v
Branches Erstelle einen neuen Branch und wechsle zu ihm: git checkout -b <branchname>
  Wechsle von einem Branch zu einem anderen: git checkout <branchname>
  Lass dir alle Branches in deinem Repository auflisten, mit der Angabe, in welchem Branch du dich aktuell befindest: git branch
  Lösche den Feature Branch: git branch -d <branchname>
  Pushe den Branch in dein Remote-Repository, damit er auch von anderen Personen verwendet werden kann: git push origin <branchname>
  Pushe alle Branches in dein Remote-Repository: git push --all origin
  Lösche einen Branch in deinem Remote-Repository: git push origin :<branchname>
Updates vom Remote-Repository Rufe Änderungen vom Remote-Server ab und führe einen Merge in dein Arbeitsverzeichnis durch: git pull
  Merge einen anderen Branch in deinen aktiven Branch: git merge <branchname>
  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 diff
git diff --base <filename>
git diff <sourcebranch> <targetbranch>
  Nachdem du alle Konflikte manuell gelöst hast, markierst du die geänderte Datei: git add <filename>
Tags Du kannst mithilfe von Tags ein bedeutendes Changeset wie z. B. einen Release kennzeichnen. git tag 1.0.0 <CommitID>
  Die CommitId besteht aus den bis zu zehn ersten Zeichen der Changeset-ID. Sie muss eindeutig sein. Du erhältst die ID über: git log
  Pushe alle Tags ins Remote-Repository: git push --tags origin
Rückgängigmachen lokaler Änderungen 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 checkout -- <filename>
  Um stattdessen alle deine lokalen Änderungen und Commits zu verwerfen, den neuesten Verlauf vom Server abzurufen und deinen lokalen Master Branch darauf zu verweisen, gehst du folgendermaßen vor: git fetch origin
git reset --hard origin/master
Suchen Suche im Arbeitsverzeichnis nach foo(): 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.

SVN Mirror for Stash (jetzt Bitbucket Server)-Plug-in

SVN Mirror for Stash ist ein Bitbucket Server-Plug-in, mithilfe dessen 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 <branchname>" einen neuen Branch erstellen oder 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 <branchname>" ganz einfach verwerfen. Wenn dir etwas gelungen ist, erstellst du einen Pull-Request und bittest darum, dass dein Branch in den Master-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.

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen