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 以外のブランチがない限りです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、プロジェクトの主要な公開リポジトリを維持する単一の担当者を選択できます。他の開発者は、このリポジトリをクローンし、それぞれ独自のクローンで作業します。満足のいく変更シリーズができた場合、変更を含むブランチからプルするようメインテナーに依頼します。メインテナーは変更を確認し、主要リポジトリにプルして、他の開発者が必要に応じて調整するためにプルできるようにします。Linux カーネルやその他のプロジェクトでは、このモデルのバリエーションが使用されています。

少人数のグループでは、開発者は中央の管理者なしに互いのリポジトリから変更をプルする可能性があります。

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

git[1] スイートの一部