日本語 ▾ トピック ▾ 最新バージョン ▾ gitcvs-migration 最終更新 2.12.5

名称

gitcvs-migration - CVSユーザーのためのGit

書式

git cvsimport *

説明

GitはCVSとは異なり、各作業ツリーにはプロジェクト履歴の完全なコピーを含むリポジトリが含まれており、本質的に他のどのリポジトリよりも重要ではありません。しかし、人々が同期できる単一の共有リポジトリを指定することで、CVSモデルをエミュレートできます。このドキュメントでは、その方法について説明します。

Gitの基本的な知識が必要です。gittutorial[7]とgitglossary[7]を一通り読めば十分でしょう。

共有リポジトリでの開発

foo.comホスト上の/pub/repo.gitに共有リポジトリが設定されているとします。その場合、個々のコミッターはssh経由で共有リポジトリを次のようにクローンできます。

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

そして開発を始めます。cvs updateに相当するのは

$ git pull origin

これは、クローン操作以降に他の人が行った作業をマージします。作業ツリーにコミットされていない変更がある場合は、git pullを実行する前にまずそれらをコミットしてください。

注

pullコマンドは、最初のgit cloneコマンドによって設定された特定の構成変数によって、どこから更新を取得するかを知っています。詳細はgit config -lとgit-config[1]のmanページを参照してください。

変更を共有リポジリに更新するには、まず変更をコミットし、次にgit pushコマンドを使用します。

$ git push origin master

それらのコミットを共有リポジトリに「プッシュ」します。他の誰かが最近リポジトリを更新している場合、cvs commitと同様にgit pushはエラーを報告します。その場合、再度プッシュを試みる前に、変更をプルする必要があります。

上記のgit pushコマンドでは、更新するリモートブランチの名前(master)を指定しています。これを省略すると、git pushはローカルリポジトリのブランチと同じ名前のリモートリポジトリ内のすべてのブランチを更新しようとします。したがって、最後のpushは次のいずれかの方法で行うことができます。

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

共有リポジトリにmaster以外のブランチがない限りは。

共有リポジトリのセットアップ

プロジェクトのGitリポジトリはすでに作成済みであると仮定します。これは、ゼロから、またはtarballから作成されたもの（gittutorial[7]を参照）、あるいは既存のCVSリポジトリからインポートされたものかもしれません（次のセクションを参照）。

既存のリポジトリが/home/alice/myprojectにあると仮定します。「bare（ベア）」リポジトリ（作業ツリーのないリポジトリ）を新規作成し、そこにプロジェクトをフェッチします。

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

次に、すべてのチームメンバーにこのリポジトリへの読み取り/書き込みアクセスを付与します。これを行う簡単な方法の1つは、リポジトリがホストされているマシンへのsshアクセスをすべてのチームメンバーに提供することです。マシン上でフルシェルを与えたくない場合は、Gitのプッシュとプルのみを許可する制限付きシェルがあります。詳細はgit-shell[1]を参照してください。

すべてのコミッターを同じグループに入れ、そのグループがリポジトリに書き込めるようにします。

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

コミッターのumaskが最大027であることを確認してください。これにより、彼らが作成するディレクトリは他のグループメンバーによって書き込み可能かつ検索可能になります。

CVSアーカイブのインポート

注
 これらの手順では、Gitに付属のgit-cvsimportスクリプトを使用しますが、他のインポーターの方が良い結果を提供する可能性があります。他のオプションについてはgit-cvsimport[1]の注記を参照してください。

まず、https://github.com/andreyvit/cvspsからcvspsのバージョン2.1以降をインストールし、それがパスに含まれていることを確認してください。次に、関心のあるプロジェクトのチェックアウトされたCVS作業ディレクトリにcdして、git-cvsimport[1]を実行します。

$ git cvsimport -C <destination> <module>

これにより、指定されたCVSモジュールのGitアーカイブが<destination>ディレクトリに格納されます。このディレクトリは必要に応じて作成されます。

インポートは、CVSからすべてのファイルすべてのリビジョンをチェックアウトします。報道によると、cvsimportは1秒あたり約20リビジョンを処理できるため、中規模プロジェクトであれば数分以上かかることはないでしょう。大規模プロジェクトやリモートリポジトリではさらに時間がかかる場合があります。

メインのトランクはoriginという名前のGitブランチに格納され、追加のCVSブランチは同じ名前のGitブランチに格納されます。メインのトランクの最新バージョンはmasterブランチにもチェックアウトされたままになるため、すぐに独自の変更を追加し始めることができます。

インポートはインクリメンタルなので、来月再度呼び出すと、その間に加えられたCVSの更新がフェッチされます。これが機能するためには、インポートされたブランチを変更してはいけません。代わりに、独自の変更用に新しいブランチを作成し、必要に応じてインポートされたブランチをマージしてください。

共有リポジトリが必要な場合は、上記で説明したように、インポートされたディレクトリのベアークローンを作成する必要があります。その後、インクリメンタルなインポートをマージする目的で、インポートされたディレクトリを別の開発クローンとして扱います。

高度な共有リポジトリ管理

Gitでは、特定の時点で実行される「フック」と呼ばれるスクリプトを指定できます。これらを使用して、例えば共有リポジトリへのすべてのコミットをメーリングリストに送信することができます。詳細はgithooks[5]を参照してください。

更新フックを使用して、よりきめ細かなパーミッションを強制できます。更新フックを使用したブランチへのアクセス制御を参照してください。

GitリポジトリへのCVSアクセス提供

開発者が引き続きCVSを使用できるように、Gitリポジトリに真のCVSアクセスを提供することも可能です。詳細はgit-cvsserver[1]を参照してください。

代替開発モデル

CVSユーザーは、開発者グループに共通リポジトリへのコミットアクセスを与えることに慣れています。ご覧のとおり、これはGitでも可能です。しかし、Gitの分散型という性質は他の開発モデルも許容しますので、まずそれらのいずれかがプロジェクトにより適しているかどうかを検討することをお勧めします。

たとえば、プロジェクトの主要な公開リポジトリを維持する単一の担当者を選ぶことができます。他の開発者はこのリポジトリをクローンし、それぞれ自分のクローン内で作業します。満足のいく一連の変更ができたら、変更を含むブランチからプルするようにメンテナーに依頼します。メンテナーは彼らの変更をレビューし、それらを主要なリポジトリにプルします。他の開発者は、連携を保つために必要に応じてこの主要リポジトリからプルします。Linuxカーネルやその他のプロジェクトでは、このモデルのバリエーションを使用しています。

小規模なグループでは、中央のメンテナーを必要とせずに、開発者同士が互いのリポジトリから変更をプルするだけでよい場合があります。

関連項目

gittutorial[7]、gittutorial-2[7]、gitcore-tutorial[7]、gitglossary[7]、giteveryday[7]、Gitユーザーマニュアル

Git

git[1]スイートの一部

scroll-to-top