既存製品の設計書はSVN、新しいサービスのコードはGitという構成では、それぞれの保管先だけでなく、どの版を組み合わせて出荷したかを記録する必要があります。
併用を続けるか統一するかは、管理するデータ、必要な連携、移行・維持にかかる作業で判断します。この記事では、併用する場合に先に決めておく管理対象とルールを整理します。
資産ごとに正本を決める
同じファイルをSVNとGitの両方で独立に更新すると、どちらを採用するかの判断が増えます。資産ごとに正式な更新先を一つ決め、複製は用途と更新方法を明示してください。
図：SVNのパスとリビジョン、GitのコミットIDをリリース記録で対応づける図。画像を開くと拡大できます。
図は、SVNの設計資産とGitのコードを別に管理し、リリース記録で版を対応づける例です。両リポジトリを相互に同期する構成ではありません。
使い分けを判断する項目
| 項目 | 確認すること |
|---|---|
| ファイルの種類 | ソース、設計書、バイナリの容量と更新方法 |
| 同時編集 | マージできるか、ロックによる調整が必要か |
| 共有範囲 | リポジトリやパスを誰に見せるか |
| 開発手順 | ブランチ、レビュー、CIが現在どう動いているか |
| 既存履歴 | 過去版の取出しや外部の参照を維持する必要があるか |
| 維持作業 | 更新、バックアップ、権限、利用手順を誰が管理するか |
Gitにも大容量ファイルを別に扱う仕組みがあります。職種だけでツールを決めず、使用するクライアントと保存サービスを含めて検証します。
リリース記録で版を対応づける
| 記録 | 残す情報 |
|---|---|
| SVNの対象 | リポジトリ、パス、確定したリビジョン |
| Gitの対象 | リポジトリ、コミットID |
| 関連資料 | 変更票、設計書、試験結果の保管先と版 |
| ビルド | コンパイラ、依存ライブラリ、設定、ビルド手順の版 |
| 配布したもの | 成果物の識別情報、配布先、確認結果 |
SVNのリビジョン番号とGitのコミットIDの間に、自動的な対応関係はありません。リリース時に使用した組合せを記録し、その組合せで取得・ビルド・確認できるかを試します。
置き場所の集約は運用作業で判断する
SVNとGitを同じサービスへ置くと、窓口や利用者管理をまとめられる場合があります。ただし、両方に対応するサービスでも、権限、バックアップ、ログの仕様が同じとは限りません。
既存のCIや認証を変更する費用、必要な機能、障害時の影響範囲を比較してください。別基盤を維持する場合も、台帳、権限申請、退職時の削除確認を共通の手順にできます。
git-svnを使う場合
git-svnは、GitからSVNを取得・更新できる双方向の連携ツールです。Gitで作業してSVNへ反映する使い方と、独立したSVN・Gitの二つを双方向ミラーとして管理する構成は区別します。
利用する場合は、SVNを正本とする運用、対応する履歴の形、ブランチとマージの扱いを公式文書で確認します。通常のGit運用と同じ手順をそのまま適用せず、検証用リポジトリで取得・反映と復旧方法を試してください。
連携が不要なら、同じ資産の二重更新は作らず、それぞれの版をリリース記録で結びます。
両方に適用する管理手順
リポジトリ台帳には、保管先、管理対象、担当者、利用者、保存期間、復元手順を記載します。異動・退職時は両方の権限を確認し、バックアップの復元もそれぞれで試します。
統一を検討する場合は、移行費用だけでなく、移行後に必要な教育、運用、連携の変更を比較します。併用の理由がなくなった時点で、残す対象を見直せる状態にしておきます。
参考資料
確認日：2026年10月6日。
関連記事
この記事の著者
株式会社オープングルーヴ／tracpath編集部。バージョン管理サービスtracpathを提供。
