私はアトラシアンに入社する前、バージョン管理システムとしてSubversion(SVN)を使用している多様なプロジェクトに携わってきました。私はすでにGitへ移行して数年経っていたので、可能な限りGitを利用したいと思いました。

そして幸運にも、git-svnを使うことができました。Git-svnは、パワフルなGitツールセットの快適な使用感を手放すことなく、Subversionリポジトリとやり取りができるすばらしい完全なソリューションです。そして、それには知っておくと便利な点がいくつかあります。この投稿では、すでにgit-svnの知識が少しあり、git-svnを使用してSVNとやり取りする方法を知っている人を対象に話を進めていきます。

ここでは、SVNと連動してGitを快適に使用し続けるために、私が自ら調べて学んできたワークフローに統合する必要のあるヒントや技をすべて紹介します。お楽しみください!

無視するファイルの設定

SVNが無視するファイルと同じファイルを必ずGitが無視するようにします。この最も簡単な技は、gitが除外するデフォルトファイルにsvn:ignoreファイルのリストを付加することです。

git svn show-ignore >> .git/info/exclude

別の方法は、魔法のupdate-indexの使用です。

git update-index --assume-unchanged files to ignore

これはかなり有効な技で、私は昨年一貫してこの技を使ってきました。詳細情報をご希望の方は、Stackoverflowに関する投稿をご覧ください。後者の手段を使う場合、実効後にGitでファイルが無視されたことを確認するには、次の方法が使えます。

git ls-files -v | grep ^[a-z] | sed -e 's/^h\ //'

注意: update-indexは直接インデックスを操作する上級コマンドなので、慎重に使用してください!

大規模リポジトリの shallow clone

以前、1.5GBを超すSVNコードベース全体のチェックアウト作業に携わったことがあります。同様の状況において、git-svnが行うような履歴全体のコミットごとの確認は、リポジトリがとにかく大き過ぎるので長々と手間がかかることがあります。この問題を回避するには、プロジェクトの履歴全体をコピーする代わりに、リポジトリのshallow cloneを作成することです。最後のnコミットをコピーし、そこから作業を開始します。以下に例を挙げます。

git svn clone -s -r604:HEAD http://nick@svn.xxxxxx.com/repos/ -T trunk -b branches -t tags

「604」を維持したい旧リビジョンと置き換える必要があります。必ず、Stackoverflowリファレンスを読んでください。

Git で誤って .svn フォルダーを追加してしまった場合

誰もが遅かれ早かれ、思わぬ障害に突き当たることでしょう。例えば、私はgit-svnを使用せずにSVNからプロジェクトを確認した時、Gitを使って自分でトラッキングをしたいと考えたことがありました。同時に、誤って.svnフォルダーをgitのインデックス(ステージング領域)に追加してしまいました。これらの重要なファイルを維持しつつ、インデックスから取り除くにはどうすればいいでしょうか? かなりの難問です! gitでファイルを実際削除することなくファイルをuntrack(未追跡)する方法を紹介します。

git status -s | grep .svn | awk {'print $3'} | xargs git rm --cached

ここでのキーワードは–cachedです。-cachedはインデックスでは機能しますが、作業ディレクトリでは機能しません。この点については、progitに関する章に非常に明確な説明があります。

SVN リポジトリが移動したらどうするか

SVN リポジトリを移動(またはVPN経由でリポジトリにアクセスし、そのアドレスを変更する何らかの賢いトンネル操作をする必要がある場合)、再度のフルチェックアウトを避けるために正確な手順を踏む必要があります。git wikiの最初に挙げられている手段で、私は一貫して成功を収めています。重要な部分をGit wikiからそのまま引用します。

  • .git/config svn-remoteURLを編集し、新しいドメイン名、または、IPアドレスを指し示す。
  • git svn fetch を実行する – これはsvnから最低1つのリビジョンをフェッチする必要があります!
  • svn-remote urlを元のurlに戻す。
  • git svn rebase -lを実行し、(最後のフェッチ操作で行われた変更とともに)ローカル リベースをする
  • svn-remote urlを、新しいurlに再び変更する。
  • git-svn rebaseを実行する。これで再び普通に機能するようになったはずです!
  • git-svn fetchステップで実際に何かをフェッチできた時にのみ、これは機能します!

結論

私はGitを使うのが好きです。完全な自由と制御を手にし、無制限にコミットでき、コミットを再フォーマットでき、そのコミットを新たなコミットへ押し込み、好きなだけブランチできます。SVNとやり取りする必要がある時でさえ、同じ楽しみを味わうことができます。私はこれを2年間ずっと行ってきました。すばらしくうまく機能します。

チーム全体がGitへ移行する体制が整ったら、総合的な作業手順説明書があると便利だと思いますので、アトラシアンが用意しました!

本稿は、Atlassian Blogs 日本語版の転載です。本文中の日時などはAtlassian Blogs 英語版での投稿当時のものですのでご了承ください。