English ▾ Themen ▾ Neueste Version ▾ gitcvs-migration zuletzt aktualisiert in 2.12.5

NAME

gitcvs-migration - Git für CVS-Benutzer

SYNOPSIS

git cvsimport *

BESCHREIBUNG

Git unterscheidet sich von CVS dadurch, dass jeder Arbeitsbaum ein Repository mit einer vollständigen Kopie der Projektgeschichte enthält und kein Repository von Natur aus wichtiger ist als jedes andere. Sie können jedoch das CVS-Modell emulieren, indem Sie ein einziges gemeinsames Repository festlegen, mit dem sich die Leute synchronisieren können; dieses Dokument erklärt, wie das geht.

Einige grundlegende Kenntnisse von Git sind erforderlich. Nach dem Durcharbeiten von gittutorial[7] und gitglossary[7] sollten Sie ausreichend vorbereitet sein.

Entwicklung gegen ein gemeinsames Repository

Angenommen, ein gemeinsames Repository ist unter /pub/repo.git auf dem Host foo.com eingerichtet. Dann können Sie als einzelner Committer das gemeinsame Repository über ssh mit

$ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project

klonen und loslegen. Das Äquivalent zu cvs update ist

$ git pull origin

was alle Arbeiten zusammenführt, die andere seit dem Klonvorgang möglicherweise geleistet haben. Wenn es nicht committete Änderungen in Ihrem Arbeitsbaum gibt, committen Sie diese zuerst, bevor Sie git pull ausführen.

Hinweis

Der Befehl pull weiß, wo er Updates beziehen soll, da bestimmte Konfigurationsvariablen vom ersten git clone Befehl gesetzt wurden; siehe git config -l und die git-config[1] Handbuchseite für Details.

Sie können das gemeinsame Repository mit Ihren Änderungen aktualisieren, indem Sie zuerst Ihre Änderungen committen und dann den Befehl git push

$ git push origin master

verwenden, um diese Commits in das gemeinsame Repository zu "pushen". Wenn jemand anderes das Repository kürzlich aktualisiert hat, wird git push, wie cvs commit, eine Fehlermeldung ausgeben, in diesem Fall müssen Sie zuerst alle Änderungen pullen, bevor Sie den Push erneut versuchen.

Im obigen git push Befehl geben wir den Namen des Remote-Branches an, der aktualisiert werden soll (master). Wenn wir dies weglassen, versucht git push, alle Branches im Remote-Repository zu aktualisieren, die denselben Namen haben wie ein Branch im lokalen Repository. Der letzte push kann also mit einem der folgenden Befehle erfolgen:

$ git push origin
$ git push foo.com:/pub/project.git/

solange das gemeinsame Repository keine anderen Branches als master hat.

Ein gemeinsames Repository einrichten

Wir gehen davon aus, dass Sie bereits ein Git-Repository für Ihr Projekt erstellt haben, möglicherweise von Grund auf neu oder aus einem Tarball (siehe gittutorial[7]), oder aus einem bereits vorhandenen CVS-Repository importiert haben (siehe nächste Abschnitt).

Angenommen, Ihr bestehendes Repository befindet sich unter /home/alice/myproject. Erstellen Sie ein neues "bare" Repository (ein Repository ohne Arbeitsbaum) und holen Sie Ihr Projekt hinein.

$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master

Geben Sie dann jedem Teammitglied Lese-/Schreibzugriff auf dieses Repository. Eine einfache Möglichkeit, dies zu tun, ist, allen Teammitgliedern SSH-Zugriff auf den Rechner zu geben, auf dem das Repository gehostet wird. Wenn Sie ihnen keine vollständige Shell auf dem Rechner geben möchten, gibt es eine eingeschränkte Shell, die Benutzern nur erlaubt, Git-Pushes und -Pulls durchzuführen; siehe git-shell[1].

Fassen Sie alle Committer in derselben Gruppe zusammen und machen Sie das Repository für diese Gruppe schreibbar.

$ chgrp -R $group /pub/my-repo.git

Stellen Sie sicher, dass die Committer eine umask von höchstens 027 haben, damit die von ihnen erstellten Verzeichnisse von anderen Gruppenmitgliedern beschreibbar und durchsuchbar sind.

Ein CVS-Archiv importieren

Hinweis
 Diese Anweisungen verwenden das Skript git-cvsimport, das mit Git geliefert wird, aber andere Importprogramme können bessere Ergebnisse liefern. Siehe den Hinweis in git-cvsimport[1] für andere Optionen.

Installieren Sie zuerst Version 2.1 oder höher von cvsps von https://github.com/andreyvit/cvsps und stellen Sie sicher, dass es sich in Ihrem Pfad befindet. Wechseln Sie dann in ein ausgechecktes CVS-Verzeichnis des interessierenden Projekts und führen Sie git-cvsimport[1] aus.

$ git cvsimport -C <destination> <module>

Dadurch wird ein Git-Archiv des benannten CVS-Moduls im Verzeichnis <destination> erstellt, das bei Bedarf erstellt wird.

Der Import checkt jede Revision jeder Datei aus CVS aus. Berichten zufolge kann cvsimport durchschnittlich etwa zwanzig Revisionen pro Sekunde verarbeiten, sodass dies bei einem mittelgroßen Projekt nicht länger als ein paar Minuten dauern sollte. Größere Projekte oder entfernte Repositories können länger dauern.

Der Haupt-Trunk wird im Git-Branch namens origin gespeichert, und zusätzliche CVS-Branches werden in Git-Branches mit denselben Namen gespeichert. Die neueste Version des Haupt-Trunks wird auch im master-Branch ausgecheckt gelassen, sodass Sie sofort mit Ihren eigenen Änderungen beginnen können.

Der Import ist inkrementell, sodass er bei erneutem Aufruf im nächsten Monat alle CVS-Updates abruft, die in der Zwischenzeit vorgenommen wurden. Damit dies funktioniert, dürfen Sie die importierten Branches nicht ändern. Erstellen Sie stattdessen neue Branches für Ihre eigenen Änderungen und führen Sie die importierten Branches bei Bedarf zusammen.

Wenn Sie ein gemeinsames Repository wünschen, müssen Sie einen Bare-Clone des importierten Verzeichnisses erstellen, wie oben beschrieben. Behandeln Sie dann das importierte Verzeichnis für die Zwecke des Zusammenführens inkrementeller Importe als einen weiteren Entwicklungs-Clone.

Erweitertes Management von gemeinsamen Repositories

Git ermöglicht es Ihnen, Skripte namens "Hooks" anzugeben, die zu bestimmten Zeitpunkten ausgeführt werden. Sie können diese beispielsweise verwenden, um alle Commits an das gemeinsame Repository an eine Mailingliste zu senden. Siehe githooks[5].

Sie können detailliertere Berechtigungen mit Update Hooks erzwingen. Siehe Zugriff auf Branches über Update Hooks steuern.

CVS-Zugriff auf ein Git-Repository bereitstellen

Es ist auch möglich, echten CVS-Zugriff auf ein Git-Repository bereitzustellen, damit Entwickler weiterhin CVS verwenden können. Siehe git-cvsserver[1] für Details.

Alternative Entwicklungsmodelle

CVS-Benutzer sind es gewohnt, einer Gruppe von Entwicklern Commit-Zugriff auf ein gemeinsames Repository zu gewähren. Wie wir gesehen haben, ist dies auch mit Git möglich. Die verteilte Natur von Git ermöglicht jedoch andere Entwicklungsmodelle, und Sie sollten sich zuerst überlegen, ob eines davon für Ihr Projekt besser geeignet ist.

Sie können beispielsweise eine einzelne Person auswählen, die das primäre öffentliche Repository des Projekts pflegt. Andere Entwickler klonen dann dieses Repository und arbeiten jeweils in ihrem eigenen Clone. Wenn sie eine Reihe von Änderungen haben, mit denen sie zufrieden sind, bitten sie den Maintainer, von dem Branch zu pullen, der die Änderungen enthält. Der Maintainer überprüft ihre Änderungen und zieht sie in das primäre Repository, von dem andere Entwickler bei Bedarf pullen, um koordiniert zu bleiben. Der Linux-Kernel und andere Projekte verwenden Varianten dieses Modells.

Bei einer kleinen Gruppe können Entwickler einfach Änderungen aus den Repositories der anderen pullen, ohne dass ein zentraler Maintainer erforderlich ist.

SIEHE AUCH

gittutorial[7], gittutorial-2[7], gitcore-tutorial[7], gitglossary[7], giteveryday[7], Das Git-Benutzerhandbuch

GIT

Teil der git[1] Suite