LASSIC Media らしくメディア
SVNからGitへの移行の5ステップ｜履歴の扱いと外注の確認点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- SVNからGitへの移行では、最新の版だけ移すか履歴ごと移すかを最初に決めます。
- 本番の前にテスト移行を行い、ファイル・ブランチ・権限・ビルドの結果を確かめます。
- 切り替えは業務時間外に一度で行い、旧SVNは読み取り専用で残しておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
SVNのサーバーが古くなってきたので、入れ替えるならGitに移りたい。けれど、長年積み上げた変更履歴をどう持っていけばよいのか分からない——。SVNで開発を続けてきた現場では、こうした迷いが起こりがちです。SVNからGitへの移行とは、ソースコードとその変更履歴を、1台のサーバーに集める仕組みから、各自の手元に履歴ごと複製する仕組みへ移し替える作業です。
ただし万能ではなく、履歴の移し方によっては情報が欠けたり、移行の手間がふくらんだりします。本記事では、SVNの運用を任された情報システムや開発の担当者に向けて、SVNとGitの違い、履歴の扱い方、移行の5ステップ、そして外部に頼むときに確認したい点を整理します。
SVNとGitの違い
Gitの公式の解説書Pro Gitは、Subversion（SVN）を、1台のサーバーがすべての版を持ち、利用者がそこからファイルを取り出す「集中型」に分類しています。一方のGitは、各自が履歴ごとリポジトリ（ファイルと変更履歴の保管場所）を丸ごと複製する「分散型」です。*4 なお、Subversionは今もApacheソフトウェア財団のプロジェクトとして開発が続いており、2026年10月には1.15.0が公開されています。*6
| 項目 | SVN | Git |
|---|---|---|
| 履歴の置き場所 | 中央のサーバーに1つ | 各自の手元にも全体の複製がある |
| ブランチ | リポジトリの中のフォルダー（trunk・branches） | リポジトリ全体の分かれ道 |
| タグ | フォルダーの写し | ある時点のリポジトリ全体のスナップショット |
| 変更した人の記録 | ユーザー名だけ | 名前とメールアドレス |
| サーバーが止まったとき | 変更を記録できない | 手元で記録を続けられる |
表のうち、ブランチとタグの持ち方と、変更した人の記録の差は、次に説明する履歴の移行に直接かかわります。SVNの「フォルダーを写してブランチを作る」運用は、Gitにそのままの形では持ち込めません。
履歴をどこまで移すか
Microsoftの移行ガイドは、多くのチームに対して、履歴を取り込まずに最新の版だけをGitに移す「ヒントの移行」を勧めています。*1 SVNではブランチがフォルダーとして存在し、名前の変更や取り消しといった細かな変更の種類も記録されます。Gitはリポジトリ全体のスナップショットとして版を持つため、1対1には置き換えられないからです。一方で、同じMicrosoftのSVN向けの手順書は、履歴を含めて移したい利用者が多いことにも触れ、その手順を示しています。*2
| 方式 | 移すもの | 向いている場面 |
|---|---|---|
| 最新の版だけ移す | trunkの最新の状態 | 過去の履歴をほとんど見返さないとき |
| 履歴ごと移す | すべての版・ブランチ・タグ | 変更の経緯をGitの上で追いたいとき |
| 期間を区切って移す | 指定した版から最新までの履歴 | 直近の経緯だけをGitで追えれば足りるとき |
どの方式でも、古いSVNはすぐに消さず、読み取り専用にして残します。Microsoftは、最新の版だけを移す場合は特に、古い仕組みを期限を設けずに残すことを強く勧めています。規制の厳しい業種では、版の履歴に法令や監査の要件がかかることもあります。*1
移行の5ステップ
SVNからGitへの移行は、変換の作業そのものより、その前後の決めごとに手間がかかります。次の5つの段階で進めると、手戻りを減らせます。
- ステップ1：いまのSVNを棚卸しする（リポジトリの構成、使っているブランチ、変更した人の一覧、大きなファイル）
- ステップ2：履歴の移し方と、Gitでのブランチの運用を決める（旧ブランチと新ブランチの対応を文書にする）
- ステップ3：テスト用のリポジトリに試しに移し、中身を確かめる
- ステップ4：業務時間外に切り替える（SVNを読み取り専用にし、残りの変更を取り込んで本番のGitへ送る）
- ステップ5：開発者への説明と、ビルド・レビューの流れを整える
ステップ3で確かめる項目は、Microsoftのガイドに具体的に挙がっています。すべてのコードのファイルが移っていること、すべてのブランチが使えること、不要なバイナリ（プログラムや画像などの文字でないファイル）が残っていないこと、利用者に取得と送信の権限があること、ビルドとテストが通ることの5つです。切り替えは、スプリントの終わりを避け、誰も変更を登録しない週末などに行うよう勧めています。*1
つまずきやすい点
履歴ごと移す場合は、変換ツールの出力をそのまま使わず、後片付けが要ります。Pro Gitも、SVNからの取り込みは完全ではないと断ったうえで、作成者の情報やタグの整理を挙げています。*3 主な手当ては次のとおりです。
- 変更した人の情報：SVNはユーザー名だけを、Gitは名前とメールアドレスを記録するため、両者の対応表を用意して置き換える*2
- タグとブランチ：変換した直後のタグはブランチの形で残るため、Gitのタグに直す
- 無視するファイルの設定：SVNのsvn:ignore（管理しないファイルの指定）を、Gitの.gitignoreに移す
- 空のフォルダー：変換ツールには空のフォルダーごとに目印のファイルを作る設定があるため、使うかどうかを決める*5
- 大きなバイナリ：一度入れると履歴とすべての複製に残るため、移行を機にリポジトリから除くか、Git LFS（大きなファイルを別に保管する仕組み）を使う*1
移行の途中もSVNで開発を続ける場合は、SVNに入った変更をGit側へ取り込み直す段階も計画に入れておきます。Microsoftの手順では、開発者がSVNを使い続けている間は変更を同期し、最後にSVNをロックして残りの変更を移します。*2
外部に頼むときに確認しておきたい点
SVNからGitへの移行を外部に頼むときは、変換の作業だけでなく、前後の決めごとをどこまで任せるかを先に決めておくと、見積もりを比べやすくなります。次の点を、依頼の前に確かめておきます。
- 範囲：棚卸し、変換、テスト移行、切り替え当日の作業、開発者への説明のうち、どれを任せるか
- 履歴の方針：最新の版だけか、履歴ごとか。履歴ごとなら、変更した人の対応表を誰が作るか
- 確かめ方：テスト移行でファイル・ブランチ・権限・ビルドとテストの結果をどう照らし合わせ、誰が合格と判断するか
- 切り替えの日時：SVNを読み取り専用にする時刻と、問題が出たときに元へ戻す手順
- 移行後の運用：Gitのサーバーの保守とバックアップ、旧SVNを残す期間
Gitのサーバーを自社で立てる場合は、移行と同時にその構築と保守の担当も決める必要があります。セルフホストでのGit基盤づくりはGitLab/Giteaによるセルフホスト Git基盤の外注構築で、より古いVisual SourceSafeからの移行はSourceSafeからGitへの移行で扱っています。
まとめ：SVNからGitへの移行で確かめておきたい3つの点
SVNからGitへの移行を進めるうえで、確かめておきたい点は3つに整理できます。第一に、最新の版だけを移すか履歴ごと移すかを、過去の履歴を見返す頻度と監査の要件から決めること。第二に、本番の前にテスト移行を行い、ファイル・ブランチ・権限・ビルドとテストの結果を確かめること。第三に、切り替えの後もSVNを読み取り専用で残し、旧ブランチとの対応を文書にしておくことです。この3点を踏まえておけば、「Gitに移したのに、昔の変更の理由を誰も追えなくなった」という事態を避けやすくなります。移行の段取りや履歴の扱いに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
移行にはどのくらいの期間がかかりますか
リポジトリの古さやブランチの数で大きく変わります。Microsoftの手順書は、trunk・branches・tagsの標準的な構成なら単純で、ブランチとマージを多く重ねていたり、構成が途中で変わっていたりすると複雑になるとしています。*2 変換そのものも規模によって数分から数時間かかるため、まずテスト移行で所要時間を測るのが確実です。
SVNのリポジトリが複数ある場合はどう進めますか
一度にすべてを移さず、リポジトリごとに順番を決めて進める方法があります。変更の少ないリポジトリから始めると、変換の手順や確かめ方を固めてから、ブランチの多いリポジトリに取りかかれます。
移行の費用は何で決まりますか
主に作業の範囲で決まります。リポジトリの数と大きさ、履歴ごと移すかどうか、移すブランチの数、テスト移行の回数、開発者への説明をどこまで含めるかが、見積もりを左右します。
SVNからGitへの移行のご相談
リポジトリの棚卸しから、履歴の移し方の設計、テスト移行と切り替え、移行後のGit基盤の運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Microsoft Learn「一元化されたバージョン管理から Git に移行する」（https://learn.microsoft.com/ja-jp/devops/develop/git/centralized-to-git）。出典：ヒントの移行の推奨、ブランチとタグの持ち方の違い、旧システムの読み取り専用での維持、バイナリとGit LFS、テスト移行で確かめる項目、業務時間外の切り替えの記述を参照（2026年10月確認）
- *2 参考：Microsoft Learn「Subversion (SVN) から Git への移行」（https://learn.microsoft.com/ja-jp/azure/devops/repos/git/perform-migration-from-svn-to-git）。出典：履歴を含めた移行の手順、移行が単純になる場合と複雑になる場合、作成者の対応表、SVNとの同期とロックの流れ、変換にかかる時間の記述を参照（2026年10月確認）
- *3 参考：Scott Chacon, Ben Straub「Pro Git」9.2 Migrating to Git（git-scm.com）（https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git）。出典：Subversionからの取り込みが完全ではないこと、作成者の対応付け、タグとブランチの後片付けの記述を参照（2026年10月確認）
- *4 参考：Scott Chacon, Ben Straub「Pro Git」1.1 About Version Control（git-scm.com）（https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control）。出典：集中型（Subversionなど）と分散型（Gitなど）のバージョン管理の説明を参照（2026年10月確認）
- *5 参考：Git公式リファレンス「git-svn」（https://git-scm.com/docs/git-svn）。出典：SubversionとGitの間の双方向のやりとり、空のフォルダーの目印ファイル、svn:ignoreの扱いの記述を参照（2026年10月確認）
- *6 参考：The Apache Software Foundation「Apache Subversion」（https://subversion.apache.org/）。出典：オープンソースの集中型バージョン管理であること、1.15.0の公開（2026年10月8日）の記述を参照（2026年10月確認）
