SYNOPSIS

git cvsimport *

DESCRIPTION

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 を実行する前にコミットしてください。

Note

pull コマンドは、最初の git clone コマンドによって設定された構成変数によって、更新をどこから取得するかを認識しています。詳細については、 git config -l および git-config(1) のマニュアルページを参照してください。

まずあなたの変更をコミットしてから、その後 git push コマンドを使用することで、あなたの変更を採用して共有リポジトリを更新できます:

$ git push origin master

それらのコミットを共有リポジトリに「プッシュ」します。他の誰かが最近リポジトリを更新した場合、「cvs commit」のように「git push」が文句を言います。その場合、プッシュを再試行する前に変更をプルする必要があります。

上記の git push コマンドで、更新するリモートブランチの名前(master)を指定します。これを省略した場合、 git push は、ローカルリポジトリ内のブランチと同じ名前を持つリモートリポジトリ内のブランチを更新しようとします。したがって、最後の「プッシュ」は以下のいずれかで実行できます:

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

上記は共有リポジトリに master 以外のブランチがない限りは動作します。

Setting Up a Shared Repository

私達は、プロジェクトのGitリポジトリをすでに作成しているか、または最初からまたはtarballから作成したか(gittutorial(7) を参照)、または既存のCVSリポジトリからインポートした(次のセクションを参照)と想定しします。

あなたの既存のリポジトリが /home/alice/myproject にあると想定します。新しい「ベア」リポジトリ(作業ツリーのないリポジトリ)を作成し、あなたのプロジェクトをそのリポジトリにフェッチします:

$ 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であることを確認してください。

Importing a CVS archive

Note
 これらの手順では、gitに付属している git-cvsimport スクリプトを使用しますが、他のインポーターがより良い結果を提供する場合があります。他のオプションについては、 git-cvsimport(1) のthe noteを参照してください。

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

$ git cvsimport -C <destination> <module>

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

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

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

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

あなたが共有リポジトリが必要な場合は、上記のように、あなたはインポートされたディレクトリのベアクローンを作成する必要があります。次に、増分インポートをマージするために、インポートされたディレクトリを別の開発クローンとして扱います。

Advanced Shared Repository Management

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

更新フックを使用して、よりきめ細かいアクセス許可を適用できます。 Controlling access to branches using update hooks (更新フックを使用したブランチへのアクセスの制御) を参照してください。

Providing CVS Access to a Git Repository

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

Alternative Development Models

CVSユーザーは、開発者のグループに共通のリポジトリへのコミットアクセスを与えることに慣れています。これまで見てきたように、これはGitでも可能です。ただし、Gitの分散性により、他の開発モデルが利用可能になるため、最初に、そのうちのどれがプロジェクトにより適しているかどうかを検討することをお勧めします。

たとえば、プロジェクトのプライマリ公開リポジトリを保守するために1人の人を選択できます。次に、他の開発者がこのリポジトリのクローンを作成し、それぞれが独自のクローンで作業します。満足のいく一連の変更がある場合、変更を含むブランチからプルするように保守者に依頼します。保守者は変更を確認し、プライマリリポジトリにプルします。プライマリリポジトリは、他の開発者が調整を維持するために必要に応じてプルします。 Linuxカーネルおよびその他のプロジェクトは、このモデルのバリエーションを使用します。

少人数のグループでは、開発者は中央の保守者を必要とせずに、互いのリポジトリから変更をプルするだけで済みます。

SEE ALSO

gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7), giteveryday(7), The Git User’s Manual

GIT

Part of the git(1) suite