---

【入門】git-svnの使い方：SubversionリポジトリをGitで管理する方法

はじめに

あなたはGitを使いたいと思っていますか？分散型バージョン管理システムの強力なブランチ機能、高速な操作、オフライン作業の可能性など、Gitの魅力は計り知れません。しかし、あなたの所属するチームやプロジェクトはまだSubversion（SVN）を使い続けているかもしれません。チーム全体の移行は難しい、あるいはすぐにはできない状況かもしれません。

そんなジレンマを解決するのが、Gitに標準で搭載されているgit-svnというツールです。git-svnを使うことで、既存のSVNリポジトリを使いながら、ローカルでの開発はGitのワークフローで行うことができるようになります。これは、SVN環境を維持しつつ、開発者個人や小規模なチームがGitの利便性を享受するための強力な手段となります。

この記事では、git-svnの基本的な使い方から、より実践的なワークフロー、さらには知っておくべき注意点やトラブルシューティングまで、詳細に解説します。SVNとGitの概念的な違いを踏まえながら説明を進めますので、GitまたはSVNの基本的な操作経験があれば理解できる内容となっています。

約5000語というボリュームで、git-svnの全体像と具体的な利用方法を網羅的に解説します。この記事を読めば、あなたの開発環境にgit-svnを導入し、SVNの制約から解放されつつ、Gitの柔軟性を手に入れることができるでしょう。

Git-SVNとは何か？

git-svnは、GitとSubversionの間で変更を同期するためのツールです。Gitコマンド群の一部として提供されており、GitリポジトリとSVNリポジトリの間で双方向の連携を可能にします。具体的には、SVNリポジトリの履歴をローカルのGitリポジトリに取り込んだり（フェッチ）、ローカルのGitリポジトリでの変更をSVNリポジトリに反映したり（プッシュに相当するコミット）できます。

git-svnが実現するのは、GitとSVNの「共存」です。SVNサーバー上のリポジトリが「真のリポジトリ」として存在し続け、git-svnユーザーはそれをGitリポジトリとしてローカルにクローンし、Gitの機能を使って開発を行い、最終的にSVNリポジトリに変更を「書き戻す」という形になります。

なぜGit-SVNを使うのか？

主な理由は、前述の通り「既存のSVN環境を維持しながら、Gitのメリットを活用したい」というニーズに応えるためです。

1. Gitのワークフローによる開発: ローカルでのコミット、ブランチ作成、マージ、リベースといったGitの高速かつ柔軟な操作が可能になります。これにより、SVNに比べて実験的な開発や機能ブランチの利用が容易になります。
2. オフライン作業: Gitは分散型であるため、一度リポジトリをクローンすれば、インターネット接続がない状態でもコミットやブランチ操作など、多くの作業を行えます。SVNのような集中型システムではこれは困難です。
3. Gitツールの利用: Git用に開発された様々なツール（GUIクライアント、diff/mergeツールとの連携、CI/CDツールとの連携など）を利用できます。
4. 段階的なGit導入: チーム全体でSVNからGitへ移行する前に、一部のメンバーがgit-svnを使ってGitのメリットを試し、習熟するためのステップとして利用できます。

この記事の目的と対象読者

この記事の目的は、git-svnを使ったことがない読者が、SVNリポジトリをGitで管理するための基本的な知識と操作方法を習得することです。単にコマンドを羅列するだけでなく、なぜそのコマンドを使うのか、そのコマンドの裏側で何が起きているのかといった概念的な部分も丁寧に説明します。

対象読者は、GitまたはSubversionの基本的な操作経験があり、git-svnに興味を持っている開発者、チームリーダー、あるいはシステム管理者などです。

Git-SVNの基本概念

git-svnを理解するためには、まずGitとSubversionの基本的な違い、そしてgit-svnがその違いをどのように橋渡ししているかを知る必要があります。

GitとSVNの基本的な違い

特徴	Git	Subversion (SVN)
モデル	分散型 (Distributed)	集中型 (Centralized)
リポジトリ	各開発者がローカルに完全な履歴を持つ	中央サーバーにのみ完全な履歴がある
コミット	ローカルリポジトリに行う	中央リポジトリに行う
ブランチ	軽量、高速、ローカルで作成/マージ可能	重い、コピーベース、サーバー操作が必要
履歴	スナップショットベース (DAG構造)	変更セットベース (線形構造)
操作	ほとんどの操作がローカルで完結	ほとんどの操作がサーバーとの通信を伴う
識別子	コミットハッシュ (SHA-1)	リビジョン番号 (整数)

これらの違いの中で、特に重要なのは「分散型 vs 集中型」、「ブランチの考え方」、「履歴の構造」です。

• 分散型 vs 集中型: Gitは各ユーザーがリポジトリの完全なコピーを持つのに対し、SVNは中央サーバーに依存します。git-svnは、ローカルのGitリポジトリをSVNサーバー上のリポジトリと同期させます。ローカルGitリポジトリは、SVNリポジトリの「ミラー」のような役割を果たしますが、Gitの機能（ローカルコミット、ブランチなど）はそのまま利用できます。
• ブランチ: Gitのブランチは非常に軽量で、単なるコミットへのポインタに過ぎません。SVNのブランチは、ディレクトリのコピーとして実装されており、Gitに比べて作成や切り替え、マージが重い操作になります。git-svnは、SVNの /trunk, /branches, /tags といった標準的なディレクトリ構造を、Gitのリモートトラッキングブランチやタグにマッピングします。
• 履歴: Gitは変更をスナップショットとして記録し、履歴はコミット間の親子関係による有向非巡回グラフ（DAG）を形成します。SVNは変更セット（差分）を線形なリビジョン番号順に記録します。git-svnは、SVNの線形なリビジョン履歴を、GitのDAG構造に変換してローカルリポジトリに保持します。各SVNリビジョンは、ローカルGitリポジトリでは一つのGitコミットに対応づけられます。

Git-SVNがSVNリポジトリをどのように扱うか

git-svnでSVNリポジトリをクローンすると、ローカルにGitリポジトリが作成されます。このGitリポジトリは、SVNリポジトリの履歴をGitのコミットとして再現したものです。各Gitコミットは、対応するSVNリビジョン番号 (git-svn-id) を持っています。

ローカルGitリポジトリには、SVNリポジトリの trunk が git-svn という名前のリモートトラッキングブランチ（デフォルト設定の場合）として、branches ディレクトリ以下の各ブランチが remotes/<branch_name> として、tags ディレクトリ以下の各タグが tags/<tag_name> として（または remotes/tags/<tag_name> として）マッピングされます。

SVNリポジトリの最新の状態は、ローカルGitリポジトリの git-svn リモートトラッキングブランチの先端コミットに対応します。

ローカルGitリポジトリとリモートSVNリポジトリの関係

操作	ローカルGitリポジトリでの変化	リモートSVNリポジトリとの関係
git commit	ローカルブランチに新しいコミットが追加される	SVNリポジトリにはまだ反映されない
git svn rebase	SVNの最新変更をフェッチし、ローカルブランチにリベースする	SVNリポジトリから最新の履歴を取得し、ローカル履歴を更新する
git svn dcommit	ローカルコミットがSVNリポジトリに新しいリビジョンとして反映される	ローカルコミットの内容がSVNリポジトリに書き込まれる
git branch	新しいローカルブランチを作成	SVNリポジトリには影響しない
git svn branch	SVNリポジトリに新しいブランチを作成するための準備をする	dcommit 時にSVNリポジトリにブランチ（ディレクトリコピー）を作成

重要な点は、git commit はローカルで完結する操作であり、この時点ではSVNリポジトリには何も影響を与えないということです。SVNリポジトリに実際に変更を反映するには、後述する git svn dcommit コマンドを使う必要があります。

Git-SVNのインストール

Git-SVNは、Gitの主要なディストリビューションに標準で含まれていることが多いツールです。したがって、別途インストールする必要はほとんどありません。

Gitに同梱されていることの説明

多くのオペレーティングシステムやパッケージマネージャーを通じてGitをインストールした場合、git svnコマンドは最初から使用可能になっています。

確認方法

コマンドライン（ターミナルまたはコマンドプロンプト）を開き、以下のコマンドを実行してみてください。

bash
git svn help

または

bash
git svn --version

これらのコマンドがヘルプメッセージやバージョン情報を表示すれば、git-svnは正しくインストールされており、使用できる状態です。

もしコマンドが見つからないといったエラーが表示される場合は、お使いのGitのインストールが最小構成であったり、特定のパッケージに含まれていなかったりする可能性があります。その場合は、お使いのOSやGitのインストール方法に合わせて、git-svnを含むパッケージを探してインストールする必要があります。（例: Debian/Ubuntuでは git-svn パッケージ、一部のWindows Gitインストーラーではオプション選択が必要な場合がある）

ただし、現代の標準的なGitインストールでは、このステップは不要な場合がほとんどです。

基本的な使い方

それでは、実際にgit-svnを使ってSVNリポジトリを操作してみましょう。

SVNリポジトリのクローン (git svn clone)

最初にSVNリポジトリをローカルのGitリポジトリとして複製します。この操作は、SVNの svn checkout とGitの git clone を組み合わせたようなものです。

基本構文

bash
git svn clone [オプション] <SVNリポジトリURL> [ローカルディレクトリ名]

<SVNリポジトリURL> は、クローンしたいSVNリポジトリのURLです。
[ローカルディレクトリ名] は、ローカルに作成されるGitリポジトリのディレクトリ名です。省略すると、SVNリポジトリURLの最後の部分から自動的に決定されます。

--stdlayout オプション

ほとんどのSVNリポジトリは、以下の標準的なディレクトリ構成を持っています。

/trunk
/branches
/tags

この標準レイアウトを採用している場合は、--stdlayout オプションを使うと便利です。

bash
git svn clone --stdlayout <SVNリポジトリURL> [ローカルディレクトリ名]

--stdlayout を指定すると、git-svn は自動的に /trunk, /branches, /tags ディレクトリを認識し、それぞれをローカルGitリポジトリの git-svn リモートトラッキングブランチ、リモートブランチ、およびタグにマッピングします。

標準レイアウトでない場合や、一部のディレクトリだけをクローンしたい場合は、代わりに --trunk, --branches, --tags オプションを使って明示的に指定します。

bash
git svn clone --trunk=path/to/trunk --branches=path/to/branches --tags=path/to/tags <SVNリポジトリURL> [ローカルディレクトリ名]

例えば、 /projectA/trunk, /projectA/branches, /projectA/tags という構成であれば、URLに /projectA までを含め、--stdlayout を指定するのが一般的です。もし / の直下に /trunk, /branches, /tags がある場合は、ルートURLに対して --stdlayout を指定します。

特定のリビジョンからクローン (-r)

非常に古いSVNリポジトリをクローンする場合、全履歴を取り込むと時間がかかることがあります。特定の過去のリビジョンから最新までだけをクローンしたい場合は、-r オプションを使います。

bash
git svn clone -r <開始リビジョン番号>:HEAD --stdlayout <SVNリポジトリURL> [ローカルディレクトリ名]

例: リビジョン1000から最新までをクローンする場合
bash
git svn clone -r 1000:HEAD --stdlayout https://your-svn-server/svn/repo my-repo

-r HEAD は最新リビジョンを意味します。-r <開始リビジョン>:<終了リビジョン> の形式で範囲を指定できますが、通常は開始リビジョンから最新 (:HEAD) までを指定します。

認証情報の設定

SVNリポジトリにアクセスするために認証が必要な場合、git svn clone 実行時にユーザー名とパスワードの入力を求められます。

bash
git svn clone ... <SVNリポジトリURL>
Username: your_svn_username
Password:

パスワードを毎回入力したくない場合は、Gitのcredential helperを設定するか、SVN自体の認証情報を利用するように設定することができます。Gitのcredential helperを使うのが推奨される方法です。

“`bash
git config –global credential.helper store

または他のcredential helper (osxkeychain, wincred, etc.)

“`

この設定を行うと、一度パスワードを入力すれば、次回からはcredential helperがパスワードを保存・提供してくれます。

クローンの進行状況と内部処理

git svn clone を実行すると、git-svn はSVNリポジトリの履歴をリビジョン順にフェッチし、それぞれのSVNリビジョンをローカルGitリポジトリのコミットとして再構築していきます。進行状況がリビジョン番号とともに表示されます。

Initialized empty Git repository in /path/to/my-repo/.git/
r1 = a1b2c3d (refs/remotes/git-svn)
r2 = e4f5g6h (refs/remotes/git-svn)
...
r100 = i1j2k3l (refs/remotes/git-svn)
...
W: Ignoring at least one merge source not in history: ^/branches/featureA:150
...
Checked out HEAD:
https://your-svn-server/svn/repo/trunk@2000

ここで表示される r<リビジョン番号> = <Gitコミットハッシュ> は、対応するSVNリビジョンとGitコミットの関係を示しています。refs/remotes/git-svn は、trunk に対応するローカルのリモートトラッキングブランチです。

注意点として、「W: Ignoring at least one merge source not in history」のような警告が表示されることがあります。これは、SVNの svn merge コマンドによるマージ履歴が、GitのDAG構造で完全に再現できない場合があることを示しています。GitとSVNのマージの概念は異なるため、これは避けられない場合があります。多くの場合、この警告は無視しても開発ワークフローに大きな影響はありませんが、複雑なSVNマージ履歴を持つリポジトリの場合は注意が必要です。

クローンが完了すると、指定したローカルディレクトリ（例: my-repo）に、.git ディレクトリを含むGitリポジトリが作成されます。

クローン直後の状態では、ローカルの作業ディレクトリは trunk の内容に対応しており、通常は master (または main) ブランチが git-svn リモートトラッキングブランチを追跡する形で作成されます。

bash
cd my-repo
git branch -a

出力例：
* master
remotes/git-svn

ここで remotes/git-svn がSVNリポジトリの trunk に対応するリモートトラッキングブランチです。ローカルの master ブランチはこれを追跡しています。

ローカルでの開発ワークフロー

git svn clone が完了したら、あとは通常のGitワークフローで開発を進めることができます。

ブランチの作成・切り替え（Gitのブランチ操作）

SVNに反映させる前のローカルでの開発は、Gitのブランチ機能を使って自由に行えます。

“`bash

新しいフィーチャーブランチを作成

git checkout -b feature/my-new-feature

作業…

“`

このブランチは完全にローカルなものであり、SVNリポジトリにはまだ存在しません。Gitの高速なブランチ切り替えやマージを存分に活用できます。

変更のコミット（Gitのコミット操作）

作業中の変更は、ローカルのGitリポジトリにコミットします。

“`bash

ファイルの変更、追加、削除…

git add .
git commit -m “Add new feature X”
“`

git commit コマンドは、あなたのローカルGitリポジトリに新しいコミットを作成するだけです。このコミットはまだSVNリポジトリには反映されていません。複数の変更を細かくコミットすることも可能です。

SVNへの変更の反映 (git svn dcommit)

ローカルでの開発（ローカルコミット）がある程度まとまったら、それをSVNリポジトリに反映させる必要があります。この操作を行うのが git svn dcommit コマンドです。

dcommit は「diff commit」の略で、ローカルのGitコミットをSVNリポジトリに「コミット」する操作です。具体的には、git svn rebase でSVNの最新変更を取り込んだ後、ローカルのHEADにあるまだSVNに反映されていないコミットを順にSVNに新しいリビジョンとして書き込みます。

基本構文

SVNに反映したいローカルブランチ（通常は master や開発ブランチ）にいる状態で実行します。

bash
git svn dcommit

ローカルコミットとSVNリビジョンの対応

git svn dcommit を実行すると、git-svn はローカルブランチのHEADから遡って、まだSVNに反映されていないコミットを探します。そして、それらのコミットを一つずつSVNリポジトリに新しいリビジョンとしてコミットします。

例えば、ローカルに3つのコミット (C1, C2, C3) があり、C0までがSVNに反映済みだとします。

(SVN r100) -- C0 -- C1 -- C2 -- C3 (ローカルHEAD)

git svn dcommit を実行すると：

1. C1がSVNにコミットされ、新しいリビジョン r101 になります。
2. C2がSVNにコミットされ、新しいリビジョン r102 になります。
3. C3がSVNにコミットされ、新しいリビジョン r103 になります。

dcommit 成功後、ローカルGitリポジトリの対応するコミットには、そのコミットがSVNのどのリビジョンとして反映されたかを示す git-svn-id 情報が追加されます。また、ローカルブランチのHEADは、SVNリポジトリの最新状態 (git-svn リモートトラッキングブランチの先端) を追跡するように更新されます。

(SVN r100) -- C0 -- C1(r101) -- C2(r102) -- C3(r103) (ローカルHEAD, git-svn)

dcommit の出力例：
Committing to https://your-svn-server/svn/repo/trunk ...
M file1.txt
A file2.txt
W: 178095ca09b343776959c636e0c15c5ff2326c6f and 1 more commits have no corresponding author in the authors file.
Author: Your Name <[email protected]>
svn-id: https://your-svn-server/svn/repo/trunk@101 r101
Committing to https://your-svn-server/svn/repo/trunk ...
M file3.txt
Author: Your Name <[email protected]>
svn-id: https://your-svn-server/svn/repo/trunk@102 r102
...

重要な注意点: git svn dcommit を実行する前に、必ず git svn rebase を実行してSVNリポジトリの最新変更を取り込み、ローカルブランチを更新しておく必要があります。もし、SVNリポジトリがあなた以外の誰かによって更新されている状態で dcommit を実行しようとすると、競合が発生する可能性があり、多くの場合 dcommit は失敗します。

マージコミットの扱い

Gitのワークフローでは、フィーチャーブランチを開発した後、master ブランチにマージ（git merge）することがよくあります。しかし、Gitのマージコミットは、複数の親を持つという点でSVNの線形な履歴構造とは相性が良くありません。

git svn dcommit は、デフォルトではマージコミットを処理できません。dcommit がコミットをSVNに反映できるのは、リベースによって作成された線形なコミット履歴のみです。

そのため、git svn を使うワークフローでは、フィーチャーブランチを master (またはSVNにdcommitする対象ブランチ) に取り込む際に、git merge ではなく git rebase を使うのが推奨されます。

“`bash

master ブランチにいると仮定

git checkout master

svn の最新を取り込む

git svn rebase

フィーチャーブランチの変更を master に取り込む（リベース）

git rebase feature/my-new-feature

svn に dcommit する

git svn dcommit
“`

この手順により、フィーチャーブランチのコミット履歴が master ブランチの先端に線形に追加され、dcommit が可能になります。

競合発生時の対応

git svn dcommit 実行中に、SVNリポジトリの最新状態とローカルの変更内容が競合する場合、dcommit は失敗します。

Conflict discovered during following:
...
Conflict: file.txt

このような場合、以下の手順で競合を解決します。

1. dcommit は中断されます。Gitは競合が発生したファイルを示します。
2. ファイルを開き、Gitのマージツールやエディタを使って競合を解決します。
3. 競合解決後、変更をステージングします (git add <解決したファイル>)。
4. 再度 git svn dcommit を実行します。dcommit は中断したところから再開し、解決済みのコミットをSVNに反映させようとします。

ただし、dcommit 時の競合は、通常 rebase 時の競合よりも解決が複雑になりがちです。そのため、dcommit 前に必ず git svn rebase を実行し、ローカルで競合を解決しておくことが強く推奨されます。

SVNからの最新変更の取り込み (git svn rebase)

他の開発者がSVNリポジトリに変更をコミットする可能性があります。ローカルでの作業を始める前や、git svn dcommit を実行する前には、必ずSVNリポジトリの最新状態をローカルに取り込む必要があります。この操作を行うのが git svn rebase コマンドです。

SVNの最新変更をフェッチし、ローカルブランチにリベースする

git svn rebase は、以下の2つの操作を連続して実行します。

1. git svn fetch: SVNリポジトリの最新の変更をフェッチし、ローカルGitリポジトリの git-svn リモートトラッキングブランチを更新します。
2. git rebase: ローカルブランチ（通常は現在チェックアウトしているブランチ）を、更新された git-svn リモートトラッキングブランチの先端にリベースします。

bash
git svn rebase

このコマンドを実行すると、git-svn はSVNリポジトリから新しいリビジョンを取得し、それをローカルの remotes/git-svn に反映します。その後、現在チェックアウトしているローカルブランチで行ったローカルコミット（まだSVNにdcommitしていないもの）を一時的に「取り出し」、remotes/git-svn の先端コミットの上にそれらのローカルコミットを一つずつ「再適用」します。

rebase 前の状態：
(SVN r100) -- C0 -- C1 -- C2 (ローカルHEAD)
\
C'1 -- C'2 (SVN r101, r102, git-svn) <- 他の誰かのコミット

git svn rebase 実行後：
(SVN r100) -- C0 -- C'1 -- C'2 -- C1' -- C2' (ローカルHEAD, git-svn)

ここで C1′ と C2′ は、C1 と C2 が C’2 の上に再適用された結果として新しく生成されたコミットです（内容はC1, C2と同じですが、親コミットが異なります）。

リベースの重要性（線形な履歴の維持）

git svn を使う上で rebase が推奨されるのは、主に以下の理由からです。

1. SVNとの互換性: SVNは基本的に線形な履歴構造を持っています。Gitの rebase はローカルのコミット履歴を線形に並べ替えるため、git svn dcommit が後続のGitコミットをSVNの新しいリビジョンとして反映しやすくなります。
2. 競合解決の容易さ: rebase はコミットを一つずつ再適用する過程で競合を検出します。これにより、複数のコミットにまたがる大規模な競合ではなく、一つのコミット適用時のより小さな競合として解決できるため、競合解決が比較的容易になります。
3. 履歴の可読性: 不要なマージコミットがなくなり、履歴が線形になるため、変更の流れが追いやすくなります。

一般的なワークフローでは、dcommit する前に必ず git svn rebase を実行し、ローカルの作業とSVNの最新状態を同期させるようにします。

競合発生時の対応

git svn rebase 実行中に競合が発生した場合、rebase は中断されます。

“`
CONFLICT (content): Merge conflict in file.txt
Failed to merge in the changes.
Patch failed at 0001 Your first local commit
Use ‘git am –show-patch’ to see the failed patch

When you have resolved this problem, run “git rebase –continue”.
If you prefer to skip this patch, run “git rebase –skip” instead.
To abort and get back to the state before the conflict, run “git rebase –abort”.
“`

競合を解決するには、以下の手順を行います。

1. Gitが示すファイルを開き、競合マーカー (<<<<<<<, =======, >>>>>>>) を参考にして内容を修正し、競合を解決します。
2. 解決したファイルをステージングします (git add <解決したファイル>)。
3. git rebase --continue を実行して、リベース処理を再開します。

リベース処理が中断と競合解決を繰り返しながら、全てのローカルコミットが正常に再適用されるまで続きます。

もし、現在のコミットの再適用を諦めたい場合は git rebase --skip を、リベース自体を取りやめて rebase 実行前の状態に戻したい場合は git rebase --abort を実行します。

より進んだ使い方・考慮事項

ブランチの扱い

git-svn におけるブランチの扱いは、GitとSVNのブランチ概念の違いを理解しておく必要があります。

SVNブランチのトラッキング (git svn branch)

標準レイアウト (/trunk, /branches, /tags) のSVNリポジトリを --stdlayout でクローンした場合、git-svn は /branches 以下の全てのブランチをローカルGitリポジトリのリモートトラッキングブランチとして (refs/remotes/<branch_name>) 自動的にトラッキングします。

SVNリポジトリに新しいブランチを作成したい場合は、git svn branch コマンドを使います。

“`bash

現在チェックアウトしているブランチをベースに、SVNに新しいブランチを作成

git svn branch
“`

このコマンドは、ローカルGitリポジトリ内に新しいリモートトラッキングブランチ refs/remotes/<new_svn_branch_name> を作成します。この時点では、SVNリポジトリにはまだブランチは作成されていません。実際にSVNリポジトリにブランチを作成するには、git svn dcommit を実行する必要があります。dcommit 時に、Git-SVNは適切なSVNコマンド（svn copy に相当する操作）を実行して、SVNリポジトリ上に新しいブランチディレクトリを作成します。

ローカルGitブランチとSVNブランチのマッピング

SVNの /trunk に対応するローカルのリモートトラッキングブランチは通常 refs/remotes/git-svn です。SVNの /branches/featureX に対応するリモートトラッキングブランチは refs/remotes/featureX となります。

ローカルでこれらのSVNブランチに対応する作業を行いたい場合は、これらのリモートトラッキングブランチを追跡するローカルブランチを作成します。

“`bash

SVNの trunk に対応するローカルブランチを作成（通常は master/main がこれに該当）

git checkout master # 既に存在する場合

SVNの branches/featureX に対応するローカルブランチを作成

git checkout -b my-feature-branch remotes/featureX
“`

git svn rebase コマンドは、現在チェックアウトしているローカルブランチが追跡しているSVNブランチ（または trunk）の最新変更をフェッチし、ローカルブランチをリベースします。

SVNブランチでの開発・コミット

ローカルGitブランチを作成し、SVNブランチ（または trunk）に対応するリモートトラッキングブランチを追跡するように設定したら、あとは通常のGitワークフローで開発を進めることができます。

“`bash

SVNの branches/featureX に対応するローカルブランチで作業

git checkout my-feature-branch

作業、git add, git commit …

変更をSVNの branches/featureX に dcommit する

git svn dcommit
“`

git svn dcommit は、現在チェックアウトしているローカルブランチが追跡しているSVNブランチに、ローカルコミットを反映させます。

SVNブランチ間のマージ

Gitではブランチ間のマージは非常に一般的ですが、SVNでは svn merge は特別な操作であり、その履歴の扱いはGitとは異なります。

git-svn を使ってSVNのブランチ間のマージをシミュレートする場合、通常はGitのリベースワークフローを利用します。例えば、branches/featureX で行った変更を trunk にマージしたい場合、ローカルでは以下のように操作します。

1. trunk に対応するローカルブランチ（例: master）に切り替える。
2. git svn rebase で trunk の最新変更を取り込む。
3. git rebase featureX のように、フィーチャーブランチの内容を master にリベースする。
4. git svn dcommit で、リベースされた変更をSVNの trunk に反映する。

これにより、SVNリポジトリ上では、フィーチャーブランチで行われた変更が trunk に新しいリビジョンとして線形に追加されることになります。Gitリポジトリの履歴も線形に保たれます。

タグの扱い

SVNリポジトリの /tags ディレクトリにある各タグは、--stdlayout でクローンした場合、ローカルGitリポジトリのタグとして自動的にインポートされます。

bash
git tag -l

これにより、SVNリポジトリからインポートされたタグの一覧を確認できます。

SVNリポジトリに新しいタグを作成したい場合は、Gitのタグを作成し、それを dcommit します。

“`bash

現在のコミットにタグを作成

git tag -a v1.0 -m “Release version 1.0”

タグと未 dcommit のコミットを SVN に反映

git svn dcommit
“`

git svn dcommit は、ローカルで作成されたGitタグも検出し、SVNリポジトリの /tags ディレクトリ以下に適切なSVNタグ（ディレクトリコピー）として作成します。

特定のブランチ・タグのみをクローン (--branches, --tags)

SVNリポジトリに多数のブランチやタグが存在する場合、全てをクローンすると時間がかかり、ローカルリポジトリのサイズも大きくなります。必要なブランチやタグだけをクローンしたい場合は、--branches および --tags オプションを使って、取り込むパスを明示的に指定できます。

bash
git svn clone --trunk=trunk --branches=branches/featureA:featureA --tags=tags/v1.0:v1.0 <SVNリポジトリURL>

この例では、trunk に加えて branches/featureA と tags/v1.0 だけを取り込みます。:featureA や :v1.0 は、ローカルGitリポジトリでのリモートトラッキングブランチ名/タグ名を指定しています。

作者情報のマッピング (--authors-file)

SVNはユーザー名をコミット情報として記録しますが、Gitは作者名とメールアドレスを記録します。git svn はデフォルトではSVNユーザー名をGitの作者名として使用しますが、Gitの標準的な 名前 <メールアドレス> 形式に変換したり、SVNユーザー名とGitユーザー名を対応付けたりするために --authors-file オプションが便利です。

bash
git svn clone --authors-file=/path/to/authors.txt ... <SVNリポジトリURL>

または、既存のローカルリポジトリで設定することも可能です。

bash
git config --local svn.authorsfile /path/to/authors.txt

authors.txt ファイルは、以下の形式で各行に SVNユーザー名 = Git作者名 を記述します。

“`
svn_user1 = Alice alice@example.com
svn_user2 = Bob bob@example.com

未定義の SVN ユーザーはデフォルトの Git ユーザー情報が使われる

“`

このファイルを適切に設定することで、クローンされたGitリポジトリのコミット履歴が、SVNの履歴に基づきつつも、Gitの標準的な作者情報を持つようになります。これにより、git log や git blame を実行した際に、より意味のある作者情報が表示されるようになります。

dcommit 時にも、ローカルのGitコミットの作者情報が、このマッピングファイル（またはGitの設定 user.name, user.email）に基づいてSVNのコミット情報に変換されます。

無視リストの変換 (.gitignore vs svn:ignore)

SVNには svn:ignore プロパティによる無視設定がありますが、Gitでは .gitignore ファイルを使用します。これらは互換性がありません。

git svn は、クローン時に svn:ignore プロパティを自動的に .gitignore に変換する機能は持っていません。手動で変換する必要があります。

もし、SVNリポジトリの svn:ignore 設定を .gitignore に引き継ぎたい場合は、クローン完了後に以下のコマンドを実行して、手動で変換・.gitignore ファイルを作成する必要があります。

bash
git svn create-ignore

このコマンドは、SVNリポジトリの無視設定を .gitignore 形式で標準出力に出力します。これをリダイレクトして .gitignore ファイルに書き込みます。

bash
git svn create-ignore > .gitignore

ただし、svn:ignore と .gitignore は記述形式が完全に一致するわけではないため、生成された .gitignore ファイルを手動で調整する必要がある場合があります。

パフォーマンスに関するヒント

大規模なSVNリポジトリや長い履歴を持つリポジトリを扱う場合、git svn clone や git svn rebase に時間がかかることがあります。

• 浅いクローン (--shallow): SVNの特定のリビジョンから最新までだけをクローンする場合に -r <開始リビジョン>:HEAD を使うのは既に述べました。これはGitの shallow clone とは異なります。git svn の clone は、SVNの指定されたリビジョン範囲の全履歴をGitコミットとして取り込みます。厳密な意味でのGitの shallow clone (一部の履歴のみを持つ) は、git svn ではサポートされていません。
• 部分的なクローンオプション: --branches, --tags を使って不要なブランチやタグの履歴を取り込まないようにすることで、クローン時間を短縮できます。
• fetch と rebase の使い分け: git svn rebase は fetch と rebase を連続して行いますが、まず git svn fetch で最新変更を取り込み、その後手動で git rebase remotes/git-svn のようにリベースを行う、という手順を踏むことも可能です。大規模な変更があった場合など、一度フェッチしてSVNの最新状態を確認してからリベースに進む、といった柔軟な対応ができます。

複数のSVNリポジトリ、または単一SVNリポジトリ内の複数プロジェクトを扱う方法

複数のSVNリポジトリ:
複数のSVNリポジトリで開発を行っている場合、それぞれのリポジトリに対して個別のGitリポジトリを作成するのが最もシンプルで推奨される方法です。

“`bash

リポジトリA 用のローカル Git リポジトリ

git svn clone –stdlayout https://your-svn-server/svn/repoA repoA_git

リポジトリB 用のローカル Git リポジトリ

git svn clone –stdlayout https://your-svn-server/svn/repoB repoB_git
“`

単一SVNリポジトリ内の複数プロジェクト:
SVNリポジトリの中には、複数のプロジェクトが /project1, /project2 のように並列に配置されている場合があります。各プロジェクトが独自の /trunk, /branches, /tags を持っているような構成です。

/
project1/
trunk/
branches/
tags/
project2/
trunk/
branches/
tags/

この場合、各プロジェクトを個別にクローンするのが一般的です。クローン時には、プロジェクトのルートをURLに含め、その中で --stdlayout を指定します。

“`bash

project1 をクローン

git svn clone –stdlayout https://your-svn-server/svn/repo/project1 project1_git

project2 をクローン

git svn clone –stdlayout https://your-svn-server/svn/repo/project2 project2_git
“`

これにより、各プロジェクトに対応する個別のGitリポジトリが作成されます。

もし、単一のローカルGitリポジトリでSVNの複数のプロジェクトを扱いたい場合は、設定ファイル (.git/config) を手動で編集し、複数の [svn-remote "<name>"] セクションを定義することで可能ですが、設定が複雑になりエラーの元となるため、あまり推奨されません。通常はプロジェクトごとにGitリポジトリを分ける方が管理しやすいです。

Git機能の限界と注意点

git-svn はGitとSVNの連携を可能にしますが、Gitの全ての機能がSVNとの間で完璧に動作するわけではありません。SVNの制約が影響します。

• 履歴の書き換え: Gitの git rebase -i や git commit --amend のような履歴を書き換える操作は、まだSVNにdcommitしていないローカルコミットに対してのみ行うべきです。一度 dcommit してSVNリビジョンとして反映されたコミットの履歴は、SVNの性質上、基本的に書き換えることができません。dcommit済みのコミットをGit側で書き換えてしまうと、次に git svn rebase や git svn dcommit を行った際に履歴の不一致が発生し、大きな問題となる可能性があります。
• マージの複雑さ: 前述の通り、Gitの複雑なマージ履歴はSVNでは表現できません。git svn ワークフローでは、rebase による線形化が推奨されます。
• サブモジュール: Gitのサブモジュールは、Gitリポジトリへの参照を別のGitリポジトリ内で管理する機能です。SVNには同等の機能がないため、Gitサブモジュールを git-svn で扱おうとすると問題が発生します。SVNの svn:externals もGitサブモジュールとは異なる概念であり、git-svn は svn:externals をGitサブモジュールに自動変換する機能はありません。
• Sparse Checkout: Gitのsparse checkout（リポジトリの一部だけをチェックアウトする機能）は、git svn での部分的なクローン (-r, --branches など) とは異なり、git svn では直接的なサポートは限定的です。クローン時にパスを指定して一部だけを取得することは可能ですが、Gitのsparse checkoutのような動的な操作は通常行いません。

Git-SVNを使った移行戦略（一時的な利用か、永続的な利用か）

git-svn を使う目的は、一時的なものか、永続的なものかによって、ワークフローやチームへの展開方法が変わってきます。

• 一時的な利用（SVNからGitへの完全移行の準備）: チーム全体でSVNからGitへ移行することを計画している場合、git-svn は一部のメンバーがGitに慣れるため、あるいは既存のSVNリポジトリをGitリポジトリとして評価するためのツールとして使えます。最終的には、svn2git のようなツールを使ってSVN履歴全体を一度Gitリポジトリに変換し、SVNの使用をやめることになります。
• 永続的な利用（GitとSVNの共存）: チーム全体がすぐにGitに移行できないが、一部のメンバーはGitを使いたいという場合、git-svn を使ったGitとSVNの共存ワークフローを継続的に行うことになります。この場合、git-svn の制約（特にdcommit 前の rebase の重要性など）を理解し、SVNユーザーとの間でどのように変更をやり取りするか（誰がSVNにコミットするのか、誰が dcommit するのか）といった運用ルールを明確にする必要があります。一般的には、Git-SVNユーザーはSVNリポジトリの trunk や主要なブランチと同期し、他のSVNユーザーもこれらのブランチを主に使用するという形になることが多いです。

Git-SVNワークフロー例

ここでは、git-svn を使った典型的な開発ワークフローの例を示します。SVNリポジトリの trunk で開発を行うシナリオを想定します。

前提：
* SVNリポジトリを git svn clone --stdlayout <SVNリポジトリURL> my-repo でクローン済み。
* ローカルGitリポジトリ (my-repo) の master ブランチで作業。master は remotes/git-svn (SVNの trunk) を追跡している。

ステップ1: 作業開始または作業再開

最新のSVNリポジトリの状態を取り込み、ローカルブランチを更新します。

bash
cd my-repo
git svn rebase

これにより、SVNに誰かがコミットした新しいリビジョンがあれば、それがローカルの master ブランチにリベースされます。競合が発生した場合は解決します。

ステップ2: フィーチャーブランチでの開発

独立したフィーチャーを開発するために、ローカルGitブランチを作成します。

bash
git checkout -b feature/new-feature

このブランチ上で、必要なコーディングを行います。

“`bash

ファイルの編集、追加、削除

git add .
git commit -m “Implement part 1 of new feature”

… さらに作業、コミット …

git commit -m “Implement part 2 of new feature”
“`

ローカルコミットは、まだSVNには反映されません。

ステップ3: SVNの最新変更を取り込む（定期的に、または dcommit 前に）

フィーチャーブランチでの作業中も、定期的にSVNリポジトリの変更を取り込むことをお勧めします。これは、後で trunk (または master) にマージ/リベースする際に、大規模な競合を避けるためです。

まず trunk に対応するローカルブランチ (master) に切り替え、SVNの最新変更を取り込みます。

bash
git checkout master
git svn rebase

次に、作業中のフィーチャーブランチを、更新された master の先端にリベースします。

bash
git checkout feature/new-feature
git rebase master

これにより、フィーチャーブランチの履歴が、SVNの最新状態の上に線形に積み重ねられます。競合が発生した場合はここで解決します。

ステップ4: フィーチャーブランチの変更を trunk (master) に統合

フィーチャーの開発が完了したら、その変更をSVNにdcommitする対象となるブランチ（ここでは master）に統合します。git-svn ワークフローでは、通常リベースを使います。

bash
git checkout master
git rebase feature/new-feature

これにより、feature/new-feature で行われたコミットが、master ブランチの先端にリベースされます。リベースが完了したら、フィーチャーブランチは削除しても構いません。

bash
git branch -d feature/new-feature

ステップ5: SVNに dcommit する

ローカルの master ブランチに、SVNにまだ反映されていないローカルコミット（リベースされたフィーチャーブランチのコミットなど）がある状態です。これをSVNリポジトリに反映します。

重要: dcommit 前に、必ずもう一度 git svn rebase を実行し、SVNの最新状態を確認し、ローカルブランチを更新します。これにより、他の開発者が rebase を実行してから dcommit するまでの間にSVNにコミットした場合の競合を防ぎます。

bash
git svn rebase # SVN の最新を取り込み、ローカル master をリベース
git svn dcommit # ローカルコミットを SVN に反映

git svn dcommit が成功すると、ローカルのコミットがSVNリポジトリに新しいリビジョンとして書き込まれます。

ステップ6: 繰り返し

ステップ1からステップ5を繰り返して開発を進めます。常に git svn rebase でSVNの最新状態を取り込み、ローカルでの開発はGitのブランチとコミットで行い、最終的に git svn dcommit でSVNに反映するというサイクルになります。

競合解決の具体的な手順（Rebase時）

git svn rebase または git rebase 時に競合が発生した場合：

1. Gitから競合ファイルのメッセージを確認します。
2. git status を実行して、競合しているファイルを確認します。
3. 競合しているファイルを開き、<<<<<<<, =======, >>>>>>> マーカーを探します。
4. マーカーを削除し、ファイルの内容を適切に修正して競合を解決します。
5. 競合を解決したファイルをステージングします (git add <ファイル名>)。
6. git rebase --continue を実行します。

Gitは次のコミットの再適用に進むか、リベースが完了するまでこのプロセスを繰り返します。

トラブルシューティング

git-svn はGitとSVNという異なるシステムを橋渡しするため、時として問題が発生することがあります。ここでは、一般的なトラブルとその対処法をいくつか紹介します。

クローン時のエラー

• 認証情報のエラー: Authentication realm ... password required
  • SVNリポジトリへのアクセスに必要なユーザー名とパスワードが正しくないか、提供されていません。クローンコマンド実行時に正しい情報を入力してください。Gitのcredential helperを設定しておくと便利です。
  • SVNサーバー側の認証設定（HTTP Basic Auth, Digest Auth, NTLM など）がGit-SVNでサポートされているか確認してください。まれに、特定の認証方式が問題を引き起こすことがあります。
• URLやレイアウトの指定間違い: Expected to find a trunk, branches and tags ...
  • --stdlayout を指定したが、SVNリポジトリが標準的な /trunk, /branches, /tags 構成になっていない場合に発生します。リポジトリの構造を確認し、--trunk, --branches, --tags オプションを使って明示的にパスを指定してください。
  • 指定したSVNリポジトリURLが間違っている、または到達できない場合もエラーになります。URLを確認し、SVNクライアントやWebブラウザでアクセス可能か試してみてください。
• SVNサーバーへの接続問題: Unable to connect to a repository
  • SVNサーバーが起動しているか、ネットワーク接続に問題がないか確認してください。ファイアウォールの設定なども確認ポイントです。
• ファイル名のエンコーディング問題: 特に古いSVNリポジトリで、Shift_JISなどの日本語ファイル名が使われている場合に問題となることがあります。Gitは通常UTF-8を扱います。Gitの core.precomposeunicode 設定や、SVNサーバー側の設定 (svn:externals, svn:ignore などに関わるエンコーディング) を確認する必要がある場合がありますが、これはかなり高度な問題になります。

git svn rebase / git svn fetch 時のエラー

• 競合: CONFLICT ... Failed to merge ...
  • 前述の「競合発生時の対応」セクションを参照し、競合を解決して git rebase --continue で処理を再開してください。
• Checksum mismatch: Checksum mismatch on ... expected 'xxx' but got 'yyy'
  • これはSVNリポジトリ自体に問題があるか、SVNサーバーとクライアント（Git-SVN）間でデータの不整合が発生したことを示します。稀なケースですが、SVNリポジトリの整合性チェック (svnadmin verify) を行ったり、SVNサーバーの管理者に相談したりする必要があるかもしれません。ローカルの .git/svn/ ディレクトリ内の関連するファイルを削除して再フェッチを試みることで解決する場合もありますが、慎重に行ってください。
• W: Ignoring at least one merge source not in history:
  • これはエラーではなく警告です。SVNのマージ履歴の一部をGitの履歴構造で完全に再現できなかったことを意味します。通常は無視しても問題ありません。

git svn dcommit 時のエラー

• 競合: Conflict discovered during following:
  • dcommit 前に git svn rebase を実行しなかったため、他の開発者の変更と競合した可能性が高いです。dcommit は中断します。競合を解決して git svn dcommit を再実行します。ただし、dcommit 時の競合解決は rebase 時よりも複雑になることがあるため、dcommit 前の rebase を徹底することが重要です。
• 履歴の不整合: Commit xxx has different trunk revision than expected または No commits to dcommit.
  • ローカルのGit履歴が、SVNリポジトリの履歴と整合性が取れなくなった場合に発生します。これは、dcommit 済みのコミットに対してGit側で履歴を書き換えてしまった場合（amend, rebase -i など）、あるいはローカルGitリポジトリの .git/svn/ ディレクトリ内の情報が破損した場合に起こり得ます。
  • 対処法としては、まずローカルの変更をstashなどで一時退避し、git reset --hard remotes/git-svn で git-svn リモートトラッキングブランチの状態に戻します。その後、退避した変更をunstackして再度コミットし、git svn rebase してから dcommit を試みます。履歴の書き換えをしてしまった場合は、その書き換えを元に戻す必要があるかもしれません。最悪の場合、リポジトリを再クローンする必要があるかもしれません。
• フック関連のエラー: svn: Commit failed (details follow):
  • SVNサーバー側のpre-commitフックなどが失敗した場合に表示されます。SVNサーバーの管理者に相談し、フックが失敗した原因を確認してください。
• Author / Committer mismatch: W: xxx and yyy more commits have no corresponding author in the authors file.
  • ローカルGitコミットのAuthor/Committer情報が、--authors-file で指定されたマッピングファイルに含まれていないSVNユーザー名に対応付けられている場合に表示されます。警告であり dcommit 自体は成功しますが、authors.txt ファイルを更新してマッピングを追加することを検討してください。

その他

• ローカルGitリポジトリのサイズが大きい: SVNリポジトリの履歴が非常に長い場合、ローカルのGitリポジトリも大きくなります。不要なブランチやタグを取り込まないように --branches / --tags オプションを使う、または定期的に新しいリビジョンからリポジトリを再クローンするなどの対策が考えられます。
• git svn info / git svn log が機能しない: .git/config ファイル内の [svn-remote] セクションの設定が壊れている可能性があります。手動で修正するか、リポジトリを再クローンすることを検討してください。

トラブルシューティングの際には、Gitコマンドの出力メッセージをよく読み、エラーの原因を特定することが重要です。必要に応じて git status, git log, gitk などのGitコマンドを使って、ローカルリポジトリの状態を確認してください。また、git svn コマンドに -v オプションをつけて詳細な出力を得ることも役立ちます。

Git-SVNの代替手段

git-svn はSVNとの共存には便利ですが、完璧なツールではありません。もしSVNからの完全移行が可能であれば、git-svn よりも効率的でGitの機能を最大限に活かせる代替手段があります。

SVNリポジトリをGitリポジトリへ完全に移行するツール (e.g., svn2git)

SVNリポジトリの履歴を完全にGitリポジトリに変換し、以降はSVNを使わずにGitのみで開発を行う場合に最適なのが、専用の移行ツールです。

最もよく使われるツールの一つに svn2git があります。これはRubyで書かれたスクリプトで、SVNの /trunk, /branches, /tags 構造をGitの master ブランチ、リモートブランチ、タグに適切に変換してくれます。--authors オプションでSVNユーザーとGitユーザーのマッピングファイルも指定できます。

svn2git の基本的な使い方（これはGit-SVNのコマンドではありません）：

“`bash

インストール（Rubyが必要）

gem install svn2git

リポジトリの変換（ローカルに Git リポジトリが作成される）

svn2git –no-minimize-url –stdlayout –authors /path/to/authors.txt
“`

svn2git を使うことで、SVNの全履歴を持つクリーンなGitリポジトリを一度作成し、以降はそのGitリポジトリをリモートとして使い、他のメンバーもそのGitリポジトリをクローンして開発するという、純粋なGitワークフローに移行できます。

Git-SVNの使い分け

では、どのような場合に git-svn を使い、どのような場合に svn2git のような完全移行ツールを使うべきでしょうか？

• git-svn を使うべきケース:
  • SVNリポジトリが「真」のリポジトリであり続ける必要がある場合（チームやプロジェクトの多くのメンバーがSVNを使い続ける）。
  • SVNからGitへの移行が難しい、あるいは計画されていないが、個人的にGitの利便性を享受したい場合。
  • 一時的にGitの機能を使ってSVNリポジトリの特定の課題に取り組みたい場合。
• svn2git (または他の移行ツール) を使うべきケース:
  • SVNからGitへ完全に移行することが決定しており、将来的にSVNを使わない場合。
  • SVNリポジトリの履歴を完全にGitリポジトリに変換し、Gitの全ての機能（履歴書き換えなども含む、ただし共有リポジトリでは非推奨）を制約なく使いたい場合。

SVNからの完全移行が最も理想的なケースが多いですが、様々な事情からそれが難しい場合に git-svn は非常に現実的な解決策となります。

まとめ

この記事では、Gitに標準で搭載されているgit-svnツールを使って、SubversionリポジトリをGitで管理する方法について詳細に解説しました。

git-svn は、既存のSVN環境に手を加えることなく、個人の開発者がローカルでGitの強力なブランチ機能、高速なコミット、オフライン作業といったメリットを享受するための有効な手段です。

基本的な使い方として、SVNリポジトリのクローン (git svn clone)、ローカルでのGitワークフロー（git commit, git branch, git rebase）、そしてSVNへの変更反映 (git svn dcommit) とSVNからの最新変更取り込み (git svn rebase) の手順を説明しました。特に、SVNの線形履歴との整合性を保つために、dcommit 前に git svn rebase を実行してローカルの履歴を線形化することの重要性を強調しました。

また、SVNブランチやタグの扱い、作者情報のマッピング (--authors-file)、パフォーマンスに関する考慮事項、単一SVNリポジトリ内の複数プロジェクトの扱い方、そしてGit-SVNを使用する上でのGit機能の限界や注意点についても詳しく解説しました。

典型的なgit-svnワークフロー例として、rebase -> ブランチ開発 -> rebase -> rebase -> dcommit という一連の流れを示し、競合発生時の具体的な解決手順も示しました。

最後に、発生しうる様々なトラブルとその対処法、そしてSVNからの完全移行を目指す場合の代替手段 (svn2gitなど) とgit-svnとの使い分けについて触れました。

git-svn はGitとSVNという異なる哲学を持つシステムを連携させるツールであるため、両方のシステムの基本的な概念とgit-svnがそれらをどのように橋渡ししているかを理解することが、効果的な利用と問題発生時の対処において非常に重要です。

この記事が、あなたがSVN環境でGitを活用するための第一歩となることを願っています。最初は戸惑うこともあるかもしれませんが、この記事で解説した基本的なコマンドとワークフローを繰り返し実践することで、git-svnを使いこなせるようになるでしょう。GitのパワーをSVNプロジェクトにも持ち込み、より快適な開発ライフを実現してください。

今後の学習ステップ

• 実際に小規模なSVNリポジトリやテスト用のSVNリポジトリを使って、この記事で紹介したコマンド (clone, rebase, dcommit, branch, tag など) を試してみてください。
• 既存のSVNリポジトリをクローンし、ローカルでフィーチャーブランチを作成して開発を行い、dcommit するサイクルを実践してみてください。
• チームメンバーの中にgit-svnに興味がある人がいれば、この記事の内容を共有し、一緒に試してみるのも良いでしょう。
• git svn の公式ドキュメント（man git-svn または git svn help）を参照し、さらに詳細なオプションや機能について学んでみてください。

SVNからGitへの完全移行が最善の解決策である場合が多いですが、git-svn は移行が難しい状況でもGitのメリットを享受するための強力なツールです。あなたの開発スタイルやチームの状況に合わせて、最適な方法を選択してください。

---