Teilen

Teilen

In SVN, developers share contributions by committing changes from a working copy on their local computer to a central repository. Then, other developers pull these updates from the central repo into their own local working copies.

Der Git Collaboration Workflow ist völlig anders. Anstatt zwischen Arbeitskopien und dem zentralen Repository zu unterscheiden, gibt Git jedem Entwickler seine eigene lokale Kopie des gesamten Repository. Änderungen werden auf dieses lokale Repository überstellt, anstatt auf ein zentrales. Um Aktualisierungen an andere Entwickler freizugeben, musst du diese lokalen Änderungen in ein öffentliches Git-Repository auf einem Server übertragen. Dann kann der andere Entwickler deine neuen Commits vom öffentlichen Repository in seine eigenen lokalen Repositories ziehen.

Git migration: Centralized SVN development vs. Distributed Git development

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.

Create a Bitbucket account

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.

Create a Bitbucket repository

Next, you’ll need to create a Bitbucket repository. Bitbucket makes it very easy to administer your hosted repositories via a web interface. All you have to do is click the Create repository button after you’ve logged in.

Git migration: Create repository

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

Git migration: Create Bitbucket repository

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.

Add an origin remote

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.

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

Stelle sicher, dass du <user> auf deinen Bitbucket Benutzernamen änderst und <repo> zum Namen des Bitbucket Repository. Du solltest auch die komplette URL vom Bitbucket Web-Interface kopieren und einfügen können.

GIt migration: Add an origin remote

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

Push the local repository to Bitbucket

Next, you need to populate your Bitbucket repository with the contents of your local Git repository. This is called “pushing,” and can be accomplished with the following command:

git 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:

git push --tags
Git migration: Push to Bitbucket repo

Your Bitbucket repository is now essentially a clone of your local repository. In the Bitbucket web interface, you should be able to explore the entire commit history of all of your branches.

Share the repository with your team

All you have to do now is share the URL of your Bitbucket repository with any other developers that need access to the repository. The URL for any Git repository can be copy-and-pasted from the repository home page on Bitbucket:

Git Migration: Share the repository

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.

Git migration: Access management of Git repositories

As an alternative, you can use Bitbucket’s built-in invitation feature to invite other developers to fork the repository. The invited users will automatically be given access to the repository, so you don’t need to worry about granting permissions.

Sobald diese die URL deines Repository haben, kann ein anderer Entwickler das Repository mit git clone auf seinen lokalen Rechner kopieren und mit der Projektarbeit beginnen. Wenn zum Beispiel der folgende Befehl auf seinem lokalen Rechner ausgeführt wurde, würde ein anderer Entwickler ein neues Git-Repository finden, das das Projekt im Verzeichnis <destination> enthält.

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

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.

Git-Migration: Änderungen am Git-Repo sollten ausschließlich vom ursprünglichen SVN-Repo stammen

Summary

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.

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen