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.
Git’s collaboration workflow is much different. Instead of differentiating between working copies and the central repository, Git gives each developer their own local copy of the entire repository. Changes are committed to this local repository instead of a central one. To share updates with other developers, you need to push these local changes to a public Git repository on a server. Then, the other developers can pull your new commits from the public repo into their own local repositories.
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).
Zugehöriges Material
Verschieben eines vollständigen Git-Repositorys
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
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.
git remote add origin https://<username>@bitbucket.org/<workspace-id>/<repo>.gitAchte 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:
git push -u origin --allDie 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.
You also need to push your local tags to the Bitbucket repository with the --tags option:
git 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.
git 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.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
