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

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

Gitに関する基本的な知識が必要です。gittutorial[7]とgitglossary[7]を読んだことがあれば十分でしょう。

foo.comというホストの/pub/repo.gitに共有リポジトリがセットアップされているとします。すると、個々のコミッターとして、ssh経由で共有リポジトリをクローンできます。

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

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

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

これらのコミットを共有リポジトリに「プッシュ」します。もし誰かが最近リポジトリを更新していた場合、git pushはcvs commitと同様に不平を言います。その場合、もう一度プッシュを試みる前に、変更をプルする必要があります。

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

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

プロジェクト用にGitリポジトリをすでに作成していると仮定します。おそらく、スクラッチから、またはtarballから作成されたもの（gittutorial[7]を参照）、または既存のCVSリポジトリからインポートされたもの（次のセクションを参照）です。

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

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

すべてのコミッターを同じグループに入れ、そのグループによってリポジトリを書き込み可能にする。

コミッターのumaskが027以下であることを確認し、作成するディレクトリが他のグループメンバーによって書き込み可能かつ検索可能であることを保証します。

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

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

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

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

インポートは増分であるため、来月再び呼び出すと、その間に加えられたCVSの更新が取得されます。これが機能するには、インポートされたブランチを変更してはなりません。代わりに、独自の変更のために新しいブランチを作成し、必要に応じてインポートされたブランチをマージしてください。

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

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

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

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

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

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

小規模なグループでは、開発者はお互いのリポジトリから変更をプルするだけで、中央のメンテナーは必要ありません。

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

git[1]スイートの一部