SVNからGitへのプロジェクトの移動

長年にわたって、SVNのみが多数のプロジェクトのバージョン管理システムとして使用されていました。 しかし、プロジェクトの1人の開発者の数が著しく増加し、プロジェクトがすでに開始されており、いくつかの機能を並行して積極的に開発し、既存のバグをオンラインで修正する必要がありました。 SVNの単一のトランクではこれが許可されず、ブランチ内のブランチの編成により、開発者の生活が地獄に変わります。 したがって、このプロジェクトをSVNからGitに移行することが決定されました。

1.中央リポジトリ用のサーバー

Gitは分散システムであるという事実にもかかわらず、すべての開発者が最終的に同期し、そこからテストビルドが展開され、運用展開が実行される中央リポジトリの必要性を排除しません。 したがって、主にサーバーが必要です。 プロジェクトは商用であるため、どういうわけかソースファイルを外部サーバーに保存したくなかったので、gitリポジトリを保存するにはサーバーを上げる必要があります。 サーバー自体はGentooで実行されるため、必要なソフトウェアをすべてインストールする必要があります。

ここでは、選択は特に大きくありません-gitosisまたはgitolite。 gitosisは数年前から開発されていないので、選択はgitoliteに落ちました。

1.1。 Gitoliteのインストール

サーバーにgitolite 3.03を配置します。

$ emerge gitolite 

これにより、将来のすべてのリポジトリを所有するgitユーザーが作成されます。

1.2。 初期設定

ここで、管理リポジトリ（gitoliteはすべての設定をgitリポジトリに保存する）にアクセスするためのrsaキーを生成し、公開キーを公開場所に保存する必要があります。

 $ ssh-keygen -t rsa $ cp ~/.ssh/id_rsa.pub /tmp/admin.pub 

その後、実際にgitoliteを初期化できます：

 $ su git $ cd $ mkdir -p bin $ gitolite/install -ln $ gitolite setup -pk /tmp/admin.pub 

1.3。 プロジェクトのリポジトリを作成する

サーバーがインストールされ、ユーザーに戻り、構成を使用してリポジトリのクローンを作成します。

 $ cd $ git clone git@server:gitolite-admin.git 

以下、serverはgitoliteがインストールされ、リポジトリが保存されるサーバーのホスト名です。

表示されたgitolite-admin / conf / gitolite.confファイルを開き、プロジェクトのリポジトリの説明を最後に追加します（これまでに1人のユーザーのみ）。

 repo project RW+ = javer 

その後、変更を保存します。 gitolite-adminで、次を実行します。

 $ git add . $ git commit -am "Repository for project added" $ git push origin master 

gitoliteは、構成に記述されていてまだ存在しないすべてのリポジトリを自動的に初期化します。

これで、gitoliteがインストールされ、最初に構成され、プロジェクトのリポジトリが作成されました。先に進むことができます。

2. SVNからプロジェクトをインポートする

SVNリポジトリをGitに直接変換するには、次のコマンドを使用します

 $ git svn clone 

このため、gitはperlサポート付きでコンパイルする必要があります。

2.1。 監査定義を開始

プロジェクトプロジェクトは、他の多くのプロジェクトとともにSVNリポジトリにあります。 リビジョン番号はリポジトリ全体を横断しているため、svn logでプロジェクトに関係する最初のコミットを見つけ、それを覚えています。 これは、最初から始まるすべてのリビジョンがスキャンされないように、インポートを高速化するために必要です。 私たちの場合、これはリビジョン19815であるため、上記のコマンドにオプションが追加されます。

 -r19815:HEAD 

2.2。 SVNユーザーとGitユーザーのマッチング

次に、SVNユーザーを将来のGitユーザーと一致させて、インポート中に正常に置き換えられるようにする必要があります。 これを行うには、どこかで次のコンテンツを含む作成者ファイルを作成します。

 javer = javer <javer@domain.tld> developer1 = developer1 <developer1@domain.tld> ... 

user@domain.tldはgitユーザーの電子メールです（gitでは、各ユーザーは名前と電子メールで識別されます）。

したがって、インポートコマンドにオプションが追加されます。

 --authors-file=/path/to/authors 

2.3。 不要なファイルの除外

さらに進んでいます。 私たちのプロジェクトでは、大きなリポジトリファイルのランダムコミットがありましたが、新しいリポジトリでは必要ありません。 それらをインポートするときに、オプションを除外できます。

 --ignore-paths="\.(avi|mov)$" 

2.4。 追加オプション

また、リポジトリにアクセスするSVNのユーザーも必要です。

 --username javer 

別のオプション--no-metadataを追加します。これは、各コメントのコミットログにフォームの追加がないようにするために必要です。

 git-svn-id: svn://svn.domain.tld/repo/project/trunk@19815 e13dc095-444b-fa4e-8f24-06838a8318a5 

プロジェクトのSVNリポジトリでは、有用な情報はトランクにのみ保存され、いくつかのブランチには一時的なコードが含まれていましたが、一時的なコードはそれでもトランクから派生したため、必要なくなりました。

2.5。 SVNリポジトリからプロジェクトを複製する

すべてをまとめて実行する：

 $ cd $ mkdir project && cd project $ git svn clone -r19815:HEAD --authors-file=/path/to/authors --ignore-paths="\.(avi|mov)$" --username javer --no-metadata svn://svn.domain.tld/repo/project/trunk . 

svn：//svn.domain.tld/repo/project/trunkは、SVNリポジトリ内のプロジェクトのトランクアドレスです。

クローン作成プロセスが開始されます。その期間は、コミットの数とそのボリュームによって異なります。 私たちの場合、約4.5千件のコミットがあり、それらのクローンを作成するのに約2時間かかりました。

2.6。 不要なファイルとディレクトリの除外

プロジェクトディレクトリでのクローン作成が完了すると、コミットの全履歴を含むプロジェクトの完全なクローンが取得されます。 クローンを作成した後、たとえば、別のリポジトリで選択するため、新しいリポジトリでは不要なディレクトリもクローンしたように見えることがあります。 次のようにして、ディレクトリとそのディレクトリへのすべての参照を履歴から削除できます。

 $ git filter-branch --tree-filter 'rm -rf unneeded_directory' -f HEAD 

また、各コミットは個別にレビューされるため、このプロセスも非常に長くなります。この場合、コミットごとに約1秒かかりました。

2.7。 空のコミットを削除する

これまでのすべてのアクションの結果として、コミットの全履歴を含むクローンプロジェクトを取得しました。その中には、空のコミット、つまり単一の変更されたファイルのないコミットがあります。 これらは、ignore-pathsオプションを介した一部のファイルの除外の結果、またはツリーフィルターを介した後続のフィルタリングの結果として現れました。 そのような空のコミットを削除するには、次のようにします。

 $ git filter-branch --commit-filter 'git_commit_non_empty_tree "$@"' HEAD 

この操作には、ツリーフィルターとほぼ同じ時間がかかります。

2.8。 空のディレクトリとsvn：無視

次に、前のsvn：ignoreを新しい.gitignoreに変換する必要があります。 これは次のように行われます。

 $ git svn create-ignore 

gitはディレクトリに関する情報のみを保存し、ファイルに関する情報のみを保存することを忘れないでください。すべての空のディレクトリで、空の.gitignoreファイルを作成し、これらのファイルをすべてコミットする必要があります。

 $ git add . $ git commit -am "Added .gitignore" 

2.9。 SVNメンションを削除

プロジェクトはSVNからGitに完全に移行しているため、SVNへのすべての参照を削除します。

 $ git branch -rd git-svn $ git config --remove-section svn-remote.svn $ git config --remove-section svn $ rm -rf .git/svn 

2.10。 svn：外観

私たちのプロジェクトでは、カスタムとパブリックの両方のいくつかのsymfonyプラグインはsvn：externals経由で接続されました。 gitにはそのようなメカニズムがないため、これにはサブモジュールを使用します。 公開プラグインを使用すると、簡単になります。

 $ git submodule add git://github.com/propelorm/sfPropelORMPlugin.git plugins/sfPropelORMPlugin $ git submodule add git://github.com/n1k0/npAssetsOptimizerPlugin.git plugins/npAssetsOptimizerPlugin 

プラグインはもう少し複雑です。プラグインを使用するには、上記のようなリポジトリを個別に作成し、同じ方法でプロジェクトに接続する必要があります。

 $ git submodule add git@server:customPlugin.git plugins/customPlugin 

サブモジュールを接続した後、それらをプロジェクトディレクトリに複製する必要があります。

 $ git submodule update --init --recursive $ git commit -am "Added submodules: sfPropelORMPlugin, npAssetsOptimizerPlugin, customPlugin" 

2.11。 プロジェクトのローカルコピーをサーバーに送信する

この操作を高速化するためにプロジェクトをサーバーに送信する前に、それを最適化します。

 $ git gc 

新しいリポジトリをプロジェクトに接続します。

 $ git remote add origin git@server:project.git 

最後に、サーバー上のプロジェクトのローカルコピーを入力します。

 $ git push origin master 

2.12。 今後のサブモジュールの更新

なぜなら、svn：externalsとは異なり、各サブモジュールは特定のコミットを指し、ローカルコピーの単純な更新を介して

 $ git pull 

サブモジュールの内容は更新されません。 更新内容は次のとおりです。

 $ git submodule update 

変更があった場合：

 $ git submodule foreach git pull $ git commit -am "Updated submodules" 

3.リポジトリのアクセス許可を設定する

3.1。 カスタムキー

リモートgitリポジトリへのアクセスはssh経由であるため、各開発者は自分のマシンでrsaキーを生成する必要があります。

3.1.1。 Linux / Unix

Linux / UnixまたはWindows上のGit bashの場合、これは次のように行われます。

 $ ssh-keygen -t rsa 

その後、受信した公開キー〜/ .ssh / id_rsa.pubがリポジトリ管理者に渡されます。

3.1.2。 窓

Windowsの場合は、puttygenを使用することもできます。これは、puttygenからダウンロードできます。

puttygenを起動し、[生成]をクリックして、キーが生成されるまでマウスをウィンドウ上にドラッグし、コメントフィールドにこのキーの目的を示し、必要に応じてキーにアクセスするためのパスワードを入力します。 その後、公開鍵フィールドの内容をコピーし、user.pubファイルに保存して、リポジトリ管理者に転送します。

次に、[秘密キーの保存]をクリックし、このキーを、たとえばTortoiseGitで使用するために人里離れた場所に保存します。

また、[変換]メニューで[OpenSSHキーのエクスポート]を選択し、C：\ Users \ USERNAME \ .ssh \ id_rsaというファイルに保存します。USERNAMEはシステム内のユーザーの名前です。 コマンドラインからgitを使用するときにこのキーが必要になります。

3.2。 権限を設定する

前の手順で取得したユーザー公開鍵は、USERNAME.pubという名前のファイルの〜/ gitolite-admin / keydir /ディレクトリの管理リポジトリに配置されます。ここで、USERNAMEはユーザー名です。

gitoliteには非常に多くのカスタマイズオプションがあるため、それらを使用してプロジェクトのリポジトリへのアクセス権を設定します。 これを行うには、ファイル〜/ gitolite-admin / conf / gitolite.confを編集し、次の形式にします：

@owners = javer
@project_developers = user1 user2 user3
@deploy = root@production

repo project
- master$ = @project_developers
- refs/tags = @project_developers
RW+ = @project_developers @owners
R = @deploy

これにより、所有者ユーザーグループへのフルアクセスが許可されます。 project_developersグループには、マスターブランチへの書き込みとタグの作成を除き、独自のブランチを作成する機能を備えたフルアクセスもあります。 実稼働環境への展開に使用される展開グループでは、読み取り専用アクセスを許可します。

最後に、すべての変更を保存することを忘れないでください：

 $ git add . $ git commit -am "New users for project: user1, user2, user3..." $ git push origin master 

4.開発者のマシンでのインストールと構成

サーバー部分は完全に準備ができており、開発マシンにgitクライアントをインストールして構成することができます。

4.1。 Linux / Unix

ここではすべてが簡単です。お気に入りのパッケージマネージャーの助けを借りてgitをインストールします。

インストール後、SVNからインポートするときに使用したものと同じ名前と電子メールを指定することを忘れないでください。

 $ git config --global user.name "javer" $ git config --global user.email "user@domain.tld" 

4.2。 窓

ここにはいくつかの異なるクライアントがありますが、これまでのところTortoiseGitに決めました。

それをインストールする前に、碑文ベータにもかかわらず、 最初に 、できれば最新バージョンのmsysgitをインストールする必要があります。 インストール中にシステムへの統合について尋ねられたら、Git bashとコマンドラインの両方からgitを実行できるように、Git Bashとコマンドプロンプトオプションを選択することをお勧めします。

その後、 TortoiseGit自体をインストールします。 ナイトリービルドではなく、最新の安定バージョンをインストールすることをお勧めします。

TortoiseGitの設定に移動し（任意のディレクトリを右クリックしてTortoiseGit->設定）、そこでGitセクションを見つけ、右側のユーザー情報ブロックに名前と電子メールを入力します。

5.移動が完了しました。 仕事を始める

以上で、SVNからGitへの移行プロセスは完了です。

各開発者はプロジェクトを自分の車に複製し、彼と一緒に作業を開始します。

開発者にこれらの記事を読むことをお勧めします。

• Git on the Fingersについて（SVNを使用した移行の場合）
• 初心者向けのチートシート