Teilen

In SVN geben Entwickler Beiträge frei, indem sie Änderungen von einer Arbeitskopie auf ihrem lokalen PC auf ein zentrales Repository überstellen. Dann rufen andere Entwickler diese Aktualisierungen vom zentralen Repo auf ihre eigenen lokalen Arbeitskopien ab.

Der Collaboration-Workflow von Git ist völlig anders. Anstatt zwischen Arbeitskopien und dem zentralen Repository zu unterscheiden, gibt Git jedem Entwickler seine eigene lokale Kopie des gesamten Repositorys. Änderungen werden in diesem lokalen Repository gespeichert und nicht in einem zentralen. Um Updates für andere Entwickler freizugeben, musst du diese lokalen Änderungen in ein öffentliches Git-Repository auf einem Server übertragen. Dann können andere Entwickler deine neuen Commits aus dem öffentlichen Repository in ihre eigenen lokalen Repositorys ziehen.

Jedem Entwickler sein eigenes komplettes Repository zu geben, ist das Kernstück der verteilten Versionskontrolle und eröffnet ein breites Angebot an möglichen Workflows. Über diese Workflows kannst du mehr unter Git-Workflows erfahren.

Bisher hast du ausschließlich mit einem lokalen Git-Repository gearbeitet. Hier wird erläutert, wie dieses lokale Repository in ein öffentliches Repository übertragen wird, das auf Bitbucketgehostet wird. Die Freigabe des Git-Repository während der Migration ermöglicht es deinem Team mit Git-Befehlen zu experimentieren, ohne dabei ihre aktive SVN-Entwicklung zu beeinträchtigen. Bis du zur Umstellung bereit sind, ist es sehr wichtig, die freigegebenen Git-Repositories als schreibgeschützt zu behandeln. Alle Entwicklung sollte weiterhin im Original-SVN-Repository stattfinden.

Ein Bitbucket-Konto erstellen

Wenn du noch kein Bitbucket -Konto hast, musst du eines erstellen. Hosting ist für bis zu 5 Benutzer kostenlos, du kannst also sofort anfangen, mit den neuen Git-Workflows zu experimentieren.

Ein Bitbucket-Repository erstellen

Als Nächstes muss du ein Bitbucket-Repository erstellen. Bitbucket macht es sehr einfach, deine gehosteten Repositories über ein Web-Interface zu verwalten. Du musst nur auf „Create repository“ (Repository erstellen) klicken, wenn du eingeloggt bist.

Gib dann in dem Formular einen Namen und eine Beschreibung für dein Repository ein. Wenn dein Projekt privat ist, lass die Option Access level (Zugriffsstufe) aktiviert, damit diese nur von designierten Entwicklern geklont werden kann. Für das Datenfeld Forking verwende „Allow only private forks“ (Nur private Forks verwenden). Verwende Git für den Repository-Typ, wähle dann ein beliebiges Projektmanagement-Tool und die primäre Programmiersprache deines Projekts unter Language (Sprache).

Um ein gehostetes Repository zu erstellen, musst du das Formular durch Klicken auf die Schaltfläche Create repository einreichen. Wenn dein Repository eingerichtet ist, siehst du eine Seite für Next steps (Nächste Schritte), die einige nützliche Befehle für den Import eines vorhandenen Projekts beschreibt. Auf dem Rest dieser Seite wirst du Schritt für Schritt durch Anleitungen geführt.

Ein Origin zum Remote hinzufügen

Um es einfacher zu machen, Commits von deinem lokalen Git-Repository in das gerade erstelle Bitbucket Repository zu übertragen, solltest du die URL des Bitbucket Repository in einem Remote aufzeichnen. Ein Remote ist einfach nur eine benutzerfreundliche Verknüpfung für eine URL. Technisch gesehen kannst du alles, was du willst für die Verknüpfung verwenden, aber wenn das Remote-Repository als offizielle Codebase für das Projekt dient, wird das in der Regel als originbezeichnet. Führe Folgendes in deinem lokalen Git-Repository aus, um dein neues Bitbucket Repository als das origin Remote hinzuzufügen.

1git remote add origin https://<username>@bitbucket.org/<workspace-id>/<repo>.git

Achte darauf, dass du ＜username＞  in deinen Bitbucket-Benutzernamen,  ＜workspace-id＞ in die ID deines Workspaces und ＜repo＞ in den Namen des Bitbucket-Repositorys änderst. Du solltest auch in der Lage sein, die vollständige URL von der Bitbucket-Weboberfläche zu kopieren und einzufügen.

Wenn der obige Befehl durchgeführt ist, kannst du origin in anderen Git-Befehlen verwenden, um auf dein Bitbucket-Repository Bezug zu nehmen.

Das lokale Repository zu Bitbucket übertragen

Anschließend musst du dein Bitbucket Repository mit den Inhalten von deinem lokalen Git-Repository auffüllen. Das wird als „pushing“ bezeichnet und kann über den folgenden Befehl erfolgen:

1git push -u origin --all

Die Option -u befiehlt Git, die Upstream Branches nachzuverfolgen. So erfährst du, ob die Commit-History des Remote-Repository vor oder hinter deinen lokalen Repositorys ist. Die Option --all überträgt die gesamten lokalen Branches zum Remote-Repository.

Du musst auch deine lokalen Tags mit der Option "--tags" zum Bitbucket-Repository übertragen:

1git push --tags

Dein Bitbucket-Repository ist jetzt im Wesentlichen ein Klon deines lokalen Repository. Im Bitbucket Web-Interface kannst du jetzt den gesamten Commit-Verlauf von allen Ihren Branches erkunden.

Das Repository an dein Team freigeben

Jetzt brauchst lediglich die URL deines Bitbucket Repository an andere Entwickler freizugeben, die Zugriff auf das Repository benötigen. Die URL für ein beliebiges Git-Repository kann von der Startseite des Repository auf Bitbucket kopiert und eingefügt werden:

Wenn dein Repository privat ist, musst du deinen Teammitgliedern Zugriff in der Registerkarte Administration (Verwaltung) des Bitbucket Web-Interface gewähren. Benutzer und Gruppen können gemanagt werden, indem auf den Link Access management (Zugriffsverwaltung) auf der linken Seitenleiste klickst.

Alternativ kannst du die in Bitbucket intrigrierte Einladungsfunktion verwenden, um andere Entwickler zum Verzweigen des Repository einzuladen. Die eingeladenen Benutzer erhalten automatisch Zugriff auf das Repository, du musst also keine Bedenken in Bezug auf die Gewährung von Autorisierungen haben.

Sobald sie die URL deines Repositorys haben, kann ein anderer Entwickler das Repository mit Git Clone auf seinen lokalen Computer kopieren und mit der Arbeit an dem Projekt beginnen. Zum Beispiel würde ein anderer Entwickler, nachdem er den folgenden Befehl auf seinem lokalen Computer ausgeführt hat, ein neues Git-Repository finden, das das Projekt im Verzeichnis mit dem Namen ＜repo＞ enthält.

1git clone https://<username>@bitbucket.org/<workspace-id>/<repo>.git

Commits gehen weiterhin an SVN, nicht an Git

Nun solltest du deine lokalen Projekte in ein Remote-Repository verschieben können und dein Team sollte die Möglichkeit haben, dieses Remote-Repository zum Klonen des Projekts auf ihre lokalen Rechner zu verwenden. Dies sind alle Tools, die du für die Zusammenarbeit mit Git benötigst. Trotzdem sollte dein Team seine Änderungen weiterhin an SVN committen, bis alle bereit für den Wechsel sind.

Die einzigen Änderungen am Git-Repository sollten über den auf der vorigen Seite beschriebenen Synchronisierungsprozess mit dem ursprünglichen SVN-Repository vorgenommen werden. Im Grunde werden deine (lokalen und Remote-) Git-Repositorys also ausschließlich gelesen. Deine Entwickler können mit ihnen experimentieren und du kannst damit beginnen, sie in deinen Build-Prozess zu integrieren, aber du solltest keine permanenten Änderungen an Git committen.

Zusammenfassung

Mit diesem Schritt richtest du ein Bitbucket-Repository ein, um dein konvertiertes Git-Repository für andere Entwickler freizugeben. Du solltest jetzt alles haben, was du zum Implementieren des Git-Workflows, wie in Git-Workflows beschrieben, benötigst. Synchronisierungen mit dem SVN-Repository kannst du weiterhin durchführen und die daraus folgenden Git-Commits über Bitbucket freigeben, bis dein Entwicklerteam ausreichend mit Git vertraut ist. Dann kannst du dein SVN-Repository deaktivieren und damit die Migration abschließen.