Git
日本語 ▾ トピック ▾ 最新バージョン ▾ git-svn は 2.47.0 で最後に更新されました

名前

git-svn - SubversionリポジトリとGit間の双方向操作

概要

git svn <command> [<options>] [<arguments>]

説明

git svnは、SubversionとGitの間で変更セットをやり取りするためのシンプルなパイプです。SubversionリポジトリとGitリポジトリの間で双方向の変更の流れを提供します。

git svnは、--stdlayoutオプションを使用して、一般的な「trunk/branches/tags」レイアウトに従って、標準のSubversionリポジトリを追跡できます。また、-T/-t/-bオプションを使用して、任意のレイアウトでブランチとタグを追跡することもできます（以下のinitのオプション、およびcloneコマンドも参照）。

（上記の方法のいずれかを使用して）Subversionリポジトリを追跡すると、GitリポジトリはfetchコマンドでSubversionから更新でき、dcommitコマンドでSubversionをGitから更新できます。

コマンド

init

git svn用の追加のメタデータディレクトリを含む空のGitリポジトリを初期化します。SubversionのURLは、コマンドライン引数として、または-T/-t/-bへの完全なURL引数として指定できます。オプションで、操作対象のターゲットディレクトリを2番目の引数として指定できます。通常、このコマンドは現在のディレクトリを初期化します。

-T<trunk-subdir>
--trunk=<trunk-subdir>
-t<tags-subdir>
--tags=<tags-subdir>
-b<branches-subdir>
--branches=<branches-subdir>
-s
--stdlayout

これらはinitのオプションのコマンドラインオプションです。これらの各フラグは、相対的なリポジトリパス (--tags=project/tags) または完全なURL (--tags=https://foo.org/project/tags) を指すことができます。Subversionリポジトリでタグやブランチが複数のパスに配置されている場合は、複数の--tagsや--branchesオプションを指定できます。--stdlayoutオプションは、trunk、tags、branchesを相対パスとして設定する省略形であり、Subversionのデフォルトです。他のオプションも指定されている場合は、そちらが優先されます。

--no-metadata

[svn-remote]設定でnoMetadataオプションを設定します。このオプションは推奨されません。このオプションを使用する前に、このマニュアルページのsvn.noMetadataセクションを読んでください。

--use-svm-props

[svn-remote]設定でuseSvmPropsオプションを設定します。

--use-svnsync-props

[svn-remote]設定でuseSvnsyncPropsオプションを設定します。

--rewrite-root=<URL>

[svn-remote]設定でrewriteRootオプションを設定します。

--rewrite-uuid=<UUID>

[svn-remote]設定でrewriteUUIDオプションを設定します。

--username=<user>

SVNが認証を処理するトランスポート（http、https、およびプレーンsvn）の場合、ユーザー名を指定します。その他のトランスポート（例：svn+ssh://）の場合、URLにユーザー名を含める必要があります。例：svn+ssh://foo@svn.bar.com/project

--prefix=<prefix>

これにより、trunk/branches/tagsが指定された場合に、リモートの名前に接頭辞を付加することができます。接頭辞には自動的に末尾のスラッシュは含まれないため、必要な場合は引数に含めるようにしてください。--branches/-bが指定された場合、接頭辞には末尾のスラッシュが含まれている必要があります。接頭辞（末尾のスラッシュ付き）を設定することを強くお勧めします。これにより、SVN追跡参照が「refs/remotes/$prefix/」に配置され、Git独自のリモート追跡参照レイアウト（refs/remotes/$remote/）と互換性があるためです。接頭辞の設定は、共通のリポジトリを共有する複数のプロジェクトを追跡する場合にも役立ちます。デフォルトでは、接頭辞はorigin/に設定されています。

注意
 Git v2.0より前は、デフォルトの接頭辞は""（接頭辞なし）でした。これは、SVN追跡参照が「refs/remotes/*」に配置され、Git独自のリモート追跡参照の編成方法と互換性がないことを意味していました。古いデフォルトが必要な場合は、コマンドラインで--prefix ""を渡すことで取得できます（PerlのGetopt::Longがv2.37より古い場合、--prefix=""は機能しない場合があります）。
--ignore-refs=<regex>

initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。--ignore-refsの説明については、fetchを参照してください。

--ignore-paths=<regex>

initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。--ignore-pathsの説明については、fetchを参照してください。

--include-paths=<regex>

initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。--include-pathsの説明については、fetchを参照してください。

--no-minimize-url

複数のディレクトリを追跡する場合（--stdlayout、--branches、または--tagsオプションを使用）、git svnはSubversionリポジトリのルート（または許可された最高レベル）に接続を試みます。このデフォルトにより、リポジトリ内でプロジェクト全体が移動した場合に履歴をより適切に追跡できますが、読み取りアクセス制限が設定されているリポジトリでは問題が発生する可能性があります。--no-minimize-urlを渡すと、git svnはより高いレベルのディレクトリに接続を試みることなく、URLをそのまま受け入れることができます。このオプションは、1つのURL/ブランチのみが追跡されている場合はデフォルトでオフになります（ほとんど効果がありません）。

fetch

追跡しているSubversionリモートからまだフェッチされていないリビジョンをフェッチします。 $GIT_DIR/configファイルの[svn-remote "…​"]セクションの名前は、オプションのコマンドライン引数として指定できます。

これにより、必要に応じてrev_mapが自動的に更新されます（詳細については、以下のFILESセクションの$GIT_DIR/svn/**/.rev_map.*を参照してください）。

--localtime

Gitのコミット時間をUTCではなくローカルタイムゾーンで保存します。これにより、git log（--date=localなしでも）で、ローカルタイムゾーンのsvn logと同じ時間が表示されます。

これは、クローンしたSubversionリポジトリとの相互運用を妨げるものではありませんが、ローカルのGitリポジトリが他の人のローカルGitリポジトリと相互運用できるようにするには、このオプションを使用しないか、同じローカルタイムゾーンで両方が使用する必要があります。

--parent

現在のHEADのSVN親のみからフェッチします。

--ignore-refs=<regex>

Perlの正規表現に一致するブランチまたはタグの参照を無視します。^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$のような「否定先読みアサーション」を使用して、特定の参照のみを許可できます。

config key: svn-remote.<name>.ignore-refs

ignore-refs設定キーが設定されており、コマンドラインオプションも指定されている場合、両方の正規表現が使用されます。

--ignore-paths=<regex>

これにより、SVNからのチェックアウトから一致するすべてのパスをスキップするPerlの正規表現を指定できます。--ignore-pathsオプションは、特定のリポジトリで（clone、dcommit、rebaseなどによる自動フェッチを含め）すべてのfetchと一致する必要があります。

config key: svn-remote.<name>.ignore-paths

ignore-paths設定キーが設定されており、コマンドラインオプションも指定されている場合、両方の正規表現が使用されます。

例

すべてのフェッチで「doc*」ディレクトリをスキップする
--ignore-paths="^doc"
最初のレベルのディレクトリの「branches」と「tags」をスキップする
--ignore-paths="^[^/]+/(?:branches|tags)"
--include-paths=<regex>

これにより、SVNからのチェックアウトから一致するパスのみを含めるPerlの正規表現を指定できます。--include-pathsオプションは、特定のリポジトリで（clone、dcommit、rebaseなどによる自動フェッチを含め）すべてのfetchと一致する必要があります。--ignore-pathsが--include-pathsよりも優先されます。

config key: svn-remote.<name>.include-paths
--log-window-size=<n>

Subversionの履歴をスキャンする際、リクエストごとに取得するログエントリ数 <n> を指定します。デフォルトは100です。非常に大規模なSubversionリポジトリの場合、clone/fetch を妥当な時間で完了させるには、より大きな値が必要になることがあります。ただし、値が大きすぎると、メモリ使用量が増加したり、リクエストがタイムアウトしたりする可能性があります。

clone

init および fetch を実行します。渡されたURLのベース名に基づいてディレクトリを自動的に作成します。または、第2引数が渡された場合は、ディレクトリを作成してその中で作業します。init および fetch コマンドが受け入れるすべての引数を受け入れますが、--fetch-all および --parent は例外です。リポジトリがクローンされた後、fetch コマンドは作業ツリーに影響を与えることなくリビジョンを更新できます。また、rebase コマンドは作業ツリーを最新の変更で更新できます。

--preserve-empty-dirs

Subversionからフェッチされた空のディレクトリごとに、ローカルのGitリポジトリにプレースホルダーファイルを作成します。これには、Subversionリポジトリ内のすべてのエントリを削除することによって空になったディレクトリ（ただし、ディレクトリ自体は削除されない）が含まれます。プレースホルダーファイルは、不要になった場合も追跡および削除されます。

--placeholder-filename=<filename>

--preserve-empty-dirs によって作成されるプレースホルダーファイルの名前を設定します。デフォルト: ".gitignore"

rebase

現在のHEADのSVN親からリビジョンをフェッチし、現在の（SVNにコミットされていない）作業をそれに対してリベースします。

これは、git rebase を使用して線形履歴を保持する点で svn update または git pull と同様に動作します。git merge の代わりに、git svn でのdcommitを容易にするためです。

これは、git svn fetch および git rebase が受け入れるすべてのオプションを受け入れます。ただし、--fetch-all は現在の [svn-remote] からのみフェッチし、すべての [svn-remote] 定義からはフェッチしません。

git rebase と同様に、これには作業ツリーがクリーンであり、コミットされていない変更がないことが必要です。

これにより、必要に応じてrev_mapが自動的に更新されます（詳細については、以下のFILESセクションの$GIT_DIR/svn/**/.rev_map.*を参照してください）。

-l
--local

リモートからフェッチせず、アップストリームSVNから最後にフェッチされたコミットに対してのみ git rebase を実行します。

dcommit

現在のブランチからの各差分をSVNリポジトリに直接コミットし、その後リベースまたはリセットします（SVNとヘッドの間に差分があるかどうかによって異なります）。これにより、Git内の各コミットに対してSVNにリビジョンが作成されます。

オプションのGitブランチ名（またはGitコミットオブジェクト名）が引数として指定されている場合、サブコマンドは現在のブランチではなく、指定されたブランチで動作します。

set-tree （下記）の代わりに dcommit を使用することをお勧めします。

--no-rebase

コミット後、リベースまたはリセットを行いません。

--commit-url <URL>

このSVN URL（フルパス）にコミットします。これは、あるトランスポート方法（例：匿名読み取りの場合は svn:// または http://）で作成された既存の git svn リポジトリが、ユーザーに後で代替トランスポート方法（例：コミットの場合は svn+ssh:// または https://）へのアクセス権が付与された場合に再利用できるようにすることを目的としています。

config key: svn-remote.<name>.commiturl
config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)

commiturl configキーのSVN URLには、SVNブランチが含まれていることに注意してください。SVNリポジトリ全体のコミットURLを設定する場合は、svn-remote.<name>.pushurl を使用してください。

他の目的でこのオプションを使用すること（質問しないでください）は、強く推奨されません。

--mergeinfo=<mergeinfo>

dcommit中に指定されたマージ情報を追加します（例：--mergeinfo="/branches/foo:1-10"）。すべてのsvnサーバーバージョンはこの情報（プロパティとして）を保存でき、バージョン1.5以降のsvnクライアントはそれを利用できます。複数のブランチからのマージ情報を指定するには、ブランチ間に1つのスペース文字を使用します（--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"）

config key: svn.pushmergeinfo

このオプションを使用すると、git-svnは、可能な場合、SVNリポジトリ内のsvn:mergeinfoプロパティを自動的に設定しようとします。現在、これは最初の親を除くすべての親がすでにSVNにプッシュされている非早送りマージをdcommitする場合にのみ実行できます。

--interactive

パッチセットを実際にSVNに送信するかどうかをユーザーに確認を求めます。各パッチに対して、「yes」（このパッチを受け入れる）、「no」（このパッチを破棄する）、「all」（すべてのパッチを受け入れる）、または「quit」と答えることができます。

答えが「no」または「quit」の場合、git svn dcommit は何もSVNにコミットせずにすぐに戻ります。

branch

SVNリポジトリにブランチを作成します。

-m
--message

コミットメッセージを指定できます。

-t
--tag

git svn init時に指定されたbranches_subdirの代わりにtags_subdirを使用してタグを作成します。

-d<path>
--destination=<path>

init または clone コマンドに複数の --branches（または --tags）オプションが指定されている場合、SVNリポジトリに作成するブランチ（またはタグ）の場所を指定する必要があります。<path> は、ブランチまたはタグの作成に使用するパスを指定し、構成されたブランチまたはタグのrefspecの左側のパターンと一致する必要があります。これらのrefspecは、次のコマンドで確認できます。

git config --get-all svn-remote.<name>.branches
git config --get-all svn-remote.<name>.tags

ここで <name> は、init への-Rオプションで指定されたSVNリポジトリの名前です（デフォルトでは "svn"）。

--username

コミットを実行するSVNユーザー名を指定します。このオプションは、username 構成プロパティをオーバーライドします。

--commit-url

指定されたURLを使用して、宛先のSubversionリポジトリに接続します。これは、ソースSVNリポジトリが読み取り専用の場合に役立ちます。このオプションは、構成プロパティ commiturl をオーバーライドします。

git config --get-all svn-remote.<name>.commiturl
--parents

親フォルダを作成します。このパラメーターは、svn cpコマンドのパラメーター --parents と同等であり、非標準のリポジトリレイアウトに役立ちます。

tag

SVNリポジトリにタグを作成します。これは branch -t の省略形です。

log

これは、svnユーザーが -r/--revision 番号を参照する場合に、svnログメッセージを簡単に検索できるようにするためのものです。

‘svn log’ の次の機能がサポートされています

-r <n>[:<n>]
--revision=<n>[:<n>]

がサポートされています。数値以外の引数はサポートされていません。HEAD、NEXT、BASE、PREVなど…

-v
--verbose

svn log の --verbose 出力と完全に互換性があるわけではありませんが、かなり近いものです。

--limit=<n>

は、--max-count と同じではありません。マージ/除外されたコミットをカウントしません。

--incremental

サポートされています

新機能

--show-commit

Gitコミットsha1も表示します

--oneline

--pretty=onelineの独自バージョン

注意
 SVN自体はUTCのみで時間を保存し、それ以外は何も保存しません。通常のsvnクライアントは、UTC時間をローカル時間（またはTZ=環境に基づく時間）に変換します。このコマンドも同じ動作をします。

その他の引数はすべて git log に直接渡されます

blame

ファイルの各行を最後に変更したリビジョンと作成者を表示します。このモードの出力は、デフォルトで ‘svn blame’ の出力と形式互換性があります。SVN blameコマンドと同様に、作業ツリー内のローカル未コミットの変更は無視されます。HEADリビジョンのファイルのバージョンが注釈付けされます。不明な引数は git blame に直接渡されます。

--git-format

git blame と同じ形式で出力を生成しますが、Gitコミットハッシュの代わりにSVNリビジョン番号を使用します。このモードでは、SVNにコミットされていない変更（ローカル作業コピーの編集を含む）はリビジョン0として表示されます。

find-rev

rN という形式のSVNリビジョン番号が指定された場合、対応するGitコミットハッシュを返します（これはオプションで、どのブランチを検索するかを指定するツリー式を続けることができます）。ツリー式が指定された場合、対応するSVNリビジョン番号を返します。

-B
--before

SVNリビジョンが指定された場合、完全一致を必須とせず、代わりに指定されたリビジョンでの（現在のブランチの）SVNリポジトリの状態に対応するコミットを検索します。

-A
--after

SVNリビジョンが指定された場合、完全一致を必須としません。完全一致がない場合は、履歴を前方検索して最も近い一致を返します。

set-tree

このコマンドの代わりに dcommit を使用することを検討する必要があります。指定されたコミットまたはツリーオブジェクトをSVNにコミットします。これは、インポートされたフェッチデータが最新であることに依存します。SVNにコミットするときにパッチを適用しようとはせず、ツリーまたはコミットで指定されたファイルでファイルを上書きするだけです。すべてのマージは、git svn 関数とは独立して行われたと想定されます。

create-ignore

ディレクトリの svn:ignore および svn:global-ignores プロパティを再帰的に検索し、一致する .gitignore ファイルを作成します。結果のファイルはコミット対象としてステージングされますが、コミットはされません。特定のrevisionを参照するには、-r/--revisionを使用します。

show-ignore

ディレクトリの svn:ignore および svn:global-ignores プロパティを再帰的に検索して一覧表示します。出力は、$GIT_DIR/info/exclude ファイルに追加するのに適しています。

mkdirs

$GIT_DIR/svn/<refname>/unhandled.log ファイルの情報に基づいて、コアGitが追跡できない空のディレクトリを再作成しようとします。空のディレクトリは "git svn clone" および "git svn rebase" の使用時に自動的に再作成されるため、"mkdirs" は "git checkout" や "git reset" などのコマンドの後に使用することを目的としています。（詳細については、svn-remote.<name>.automkdirs configファイルオプションを参照してください。）

commit-diff

コマンドラインからの2つのツリー式の引数の差分をコミットします。このコマンドは、git svn init されたリポジトリ内にあることに依存しません。このコマンドは、(a) 差分の元のツリー、(b) 新しいツリーの結果、(c) ターゲットSubversionリポジトリのURLという3つの引数を取ります。最後の引数（URL）は、git svn 対応のリポジトリ（git svn で init されたリポジトリ）から作業している場合は省略できます。この場合は -r<revision> オプションが必要です。

コミットメッセージは、-m または -F オプションで直接指定するか、2番目の tree-ish がそのようなオブジェクトを示す場合はタグまたはコミットから間接的に取得するか、エディターを起動して要求します (以下の --edit オプションを参照)。

-m <msg>
--message=<msg>

指定された msg をコミットメッセージとして使用します。このオプションは --edit オプションを無効にします。

-F <filename>
--file=<filename>

指定されたファイルからコミットメッセージを取得します。このオプションは --edit オプションを無効にします。

info

ファイルまたはディレクトリに関する情報を、'svn info' が提供するものと同様に表示します。現在、-r/--revision 引数はサポートされていません。URL: フィールドの値のみを出力するには、--url オプションを使用します。

proplist

指定されたファイルまたはディレクトリについて、Subversion リポジトリに保存されているプロパティを一覧表示します。特定の Subversion リビジョンを参照するには、-r/--revision を使用します。

propget

ファイルについて、最初の引数として指定された Subversion プロパティを取得します。特定の revision は、-r/--revision で指定できます。

propset

最初の引数として指定された Subversion プロパティを、3番目の引数として指定されたファイルに対して、2番目の引数として指定された値に設定します。

例

git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

これにより、ファイル *devel/py-tipper/Makefile* のプロパティ *svn:keywords* が *FreeBSD=%H* に設定されます。

show-externals

Subversion の外部定義を表示します。特定の revision を指定するには、-r/--revision を使用します。

gc

$GIT_DIR/svn/<refname>/unhandled.log ファイルを圧縮し、$GIT_DIR/svn/<refname>/index ファイルを削除します。

reset

指定されたリビジョンまで fetch の効果を元に戻します。これにより、SVN リビジョンを再 fetch することができます。通常、SVN リビジョンの内容は決して変更されるべきではなく、reset は必要ありません。ただし、SVN の権限が変更されたり、--ignore-paths オプションを変更した場合、fetch が「コミットに見つかりません」(以前は表示されていなかったファイル) または「チェックサムの不一致」(修正を見逃した) で失敗することがあります。問題のファイルを永久に無視できない場合 (--ignore-paths)、リポジトリを修復する唯一の方法は reset を使用することです。

rev_map と refs/remotes/git-svn のみが変更されます (詳細については、以下の FILES セクションの $GIT_DIR/svn/**/.rev_map.* を参照)。reset の後に fetch を実行し、その後 git reset または git rebase を使用してローカルブランチを新しいツリーに移動します。

-r <n>
--revision=<n>

保持する最新のリビジョンを指定します。それ以降のリビジョンはすべて破棄されます。

-p
--parent

指定されたリビジョンも破棄し、代わりに最も近い親を保持します。

例

「master」にローカルな変更があるが、「r2」を再フェッチする必要があると仮定します。

    r1---r2---r3 remotes/git-svn
                \
                 A---B master

そもそも「r2」が不完全になった原因である ignore-paths または SVN の権限の問題を修正します。それから

git svn reset -r2 -p
git svn fetch
    r1---r2'--r3' remotes/git-svn
      \
       r2---r3---A---B master

次に、git rebase で「master」を修正します。git merge を使用しないでください。そうしないと、履歴が将来の dcommit と互換性がなくなります。

git rebase --onto remotes/git-svn A^ master
    r1---r2'--r3' remotes/git-svn
                \
                 A'--B' master

オプション

--shared[=(false|true|umask|group|all|world|everybody)]
--template=<template-directory>

init コマンドでのみ使用されます。これらは git init に直接渡されます。

-r <arg>
--revision <arg>

fetch コマンドで使用されます。

これにより、部分的な/焼却された履歴のリビジョン範囲がサポートされます。$NUMBER、$NUMBER1:$NUMBER2 (数値範囲)、$NUMBER:HEAD、BASE:$NUMBER がすべてサポートされます。

これにより、fetch の実行時に部分的なミラーを作成できます。ただし、通常は履歴がスキップされて失われるため、お勧めしません。

-
--stdin

set-tree コマンドでのみ使用されます。

stdin からコミットのリストを読み取り、それらを逆順でコミットします。各行から先頭の sha1 のみが読み取られるため、*git rev-list --pretty=oneline* の出力を使用できます。

--rmdir

dcommit、set-tree および commit-diff コマンドでのみ使用されます。

ファイルが残っていない場合は、SVN ツリーからディレクトリを削除します。SVN は空のディレクトリをバージョン管理でき、ファイルが残っていない場合でもデフォルトでは削除されません。Git は空のディレクトリをバージョン管理できません。このフラグを有効にすると、SVN へのコミットが Git のように動作します。

config key: svn.rmdir
-e
--edit

dcommit、set-tree および commit-diff コマンドでのみ使用されます。

SVN にコミットする前に、コミットメッセージを編集します。これは、コミットであるオブジェクトに対してはデフォルトでオフになり、ツリーオブジェクトをコミットする場合は強制的にオンになります。

config key: svn.edit
-l<num>
--find-copies-harder

dcommit、set-tree および commit-diff コマンドでのみ使用されます。

これらは両方とも git diff-tree に直接渡されます。詳細については、git-diff-tree[1] を参照してください。

config key: svn.l
config key: svn.findcopiesharder
-A<filename>
--authors-file=<filename>

構文は、*git cvsimport* で使用されるファイルと互換性がありますが、空のメールアドレスを <> で指定できます。

	loginname = Joe User <user@example.com>

このオプションが指定され、*git svn* が authors-file に存在しない SVN コミッター名に遭遇した場合、*git svn* は操作を中止します。ユーザーは、適切なエントリを追加する必要があります。authors-file が変更された後、以前の *git svn* コマンドを再実行すると、操作が続行されます。

config key: svn.authorsfile
--authors-prog=<filename>

このオプションが指定されている場合、authors ファイルに存在しない SVN コミッター名ごとに、指定されたファイルがコミッター名を最初の引数として実行されます。プログラムは、"Name <email>" または "Name <>" の形式の単一行を返すことが期待されており、これは authors ファイルに含まれるものとして扱われます。

履歴上の理由から、相対的な filename は、まず init および clone の場合は現在のディレクトリを基準にして、fetch の場合はワーキングツリーのルートを基準にして検索されます。filename が見つからない場合は、*PATH* の他のコマンドと同様に検索されます。

config key: svn.authorsProg
-q
--quiet

git svn の冗長性を抑えます。2回指定すると、さらに冗長性が抑えられます。

-m
--merge
-s<strategy>
--strategy=<strategy>
-p
--rebase-merges

これらは dcommit および rebase コマンドでのみ使用されます。

git reset が使用できない場合に dcommit を使用すると、git rebase に直接渡されます (dcommit を参照)。

-n
--dry-run

これは、*dcommit*、*rebase*、*branch* および *tag* コマンドで使用できます。

dcommit の場合、SVN にコミットされる diff を示す Git 引数のシリーズを出力します。

rebase の場合、現在のブランチに関連付けられたアップストリーム svn リポジトリと、フェッチされる svn リポジトリの URL に関連付けられたローカルブランチを表示します。

branch と tag の場合、ブランチまたはタグを作成するときにコピーに使用される URL を表示します。

--use-log-author

Git に svn コミットを取得する際 (fetch、rebase、または dcommit 操作の一部として)、ログメッセージの最初の From: 行または Signed-off-by トレーラーを探し、それを作者文字列として使用します。

config key: svn.useLogAuthor
--add-author-from

Git から svn にコミットするとき (set-tree または dcommit 操作の一部として)、既存のログメッセージに From: または Signed-off-by トレーラーがまだない場合は、Git コミットの作者文字列に基づいて From: 行を追加します。これを使用すると、--use-log-author はすべてのコミットに対して有効な作者文字列を取得します。

config key: svn.addAuthorFrom

高度なオプション

-i<GIT_SVN_ID>
--id <GIT_SVN_ID>

これにより、GIT_SVN_ID が設定されます (環境変数を使用する代わりに)。これにより、ユーザーは単一の URL を追跡するときにフェッチするデフォルトの refname をオーバーライドできます。log および dcommit コマンドは、引数としてこのスイッチを必要としなくなりました。

-R<remote-name>
--svn-remote <remote-name>

使用する [svn-remote "<remote-name>"] セクションを指定します。これにより、SVN の複数のリポジトリを追跡できます。デフォルト: "svn"

--follow-parent

このオプションは、ブランチを追跡している場合 (リポジトリレイアウトオプションのいずれかを使用している場合 --trunk, --tags, --branches, --stdlayout) にのみ関連します。追跡された各ブランチについて、そのリビジョンがどこからコピーされたかを調べ、ブランチの最初の Git コミットに適切な親を設定します。これは、リポジトリ内で移動されたディレクトリを追跡する場合に特に役立ちます。この機能が無効になっている場合、*git svn* によって作成されたブランチはすべて線形になり、履歴を共有しないため、ブランチがどこから分岐またはマージされたかに関する情報はありません。ただし、長くて複雑な履歴を追跡するには時間がかかる可能性があるため、この機能を無効にすると、クローン作成プロセスが高速化される場合があります。この機能はデフォルトで有効になっています。無効にするには --no-follow-parent を使用します。

config key: svn.followparent

設定ファイルのみのオプション

svn.noMetadata
svn-remote.<name>.noMetadata

これにより、すべてのコミットの末尾にある *git-svn-id:* 行が削除されます。

このオプションは、一度限りのインポートにのみ使用できます。これは、*git svn* がメタデータなしで再度フェッチできなくなるためです。さらに、*$GIT_DIR/svn/**/.rev_map.* ファイルを失った場合、*git svn* はそれらを再構築できません。

git svn log コマンドも、これを使用しているリポジトリでは機能しません。これを使用すると、(うまくいけば) 明らかな理由で useSvmProps オプションと競合します。

このオプションは、既存のドキュメント、バグレポート、およびアーカイブで SVN リビジョン番号への古い参照を追跡するのが難しくなるため、お勧めしません。SVN から Git に最終的に移行することを計画しており、SVN 履歴を削除することを確信している場合は、代わりに git-filter-repo を検討してください。filter-repo では、読みやすくするためのメタデータの再フォーマットや、"svn.authorsFile" ユーザー以外向けの作成者情報の書き換えも可能です。

svn.useSvmProps
svn-remote.<name>.useSvmProps

これは、SVN::Mirror (または svk) を使用して作成されたミラーから、メタデータのためにリポジトリ URL と UUID を再マッピングするために、git svn が使用できるようにします。

SVN リビジョンに "svm:headrev" というプロパティがある場合、そのリビジョンは SVN::Mirror (SVK でも使用) によって作成された可能性が高くなります。このプロパティには、リポジトリ UUID とリビジョンが含まれています。元の URL をミラーリングしているように見せたいので、元の ID URL と UUID を返すヘルパー関数を導入し、コミットメッセージでメタデータを生成するときに使用します。

svn.useSvnsyncProps
svn-remote.<name>.useSvnsyncprops

useSvmProps オプションと同様に、これは SVN 1.4.x 以降に付属する svnsync(1) コマンドのユーザー向けです。

svn-remote.<name>.rewriteRoot

これにより、ユーザーは代替 URL からリポジトリを作成できます。たとえば、管理者はローカルで (file:// 経由でアクセスして) git svn をサーバー上で実行できますが、リポジトリを配布する際に、メタデータにパブリックな http:// または svn:// URL を使用して、ユーザーがパブリック URL を確認できるようにしたい場合があります。

svn-remote.<name>.rewriteUUID

useSvmProps オプションと同様に、これは UUID を手動で再マッピングする必要があるユーザー向けです。これは、元の UUID が useSvmProps または useSvnsyncProps のどちらでも利用できない場合に役立ちます。

svn-remote.<name>.pushurl

Git の remote.<name>.pushurl と同様に、このキーは、url が読み取り専用トランスポートを介して SVN リポジトリを指している場合に、代替の読み取り/書き込みトランスポートを提供するために設計されています。両方のキーが同じリポジトリを指していると想定されます。commiturl とは異なり、pushurl はベースパスです。commiturl または pushurl のどちらかが使用できる場合、commiturl が優先されます。

svn.brokenSymlinkWorkaround

これは、壊れたクライアントによって SVN にチェックインされた壊れたシンボリックリンクを回避するための、潜在的にコストのかかるチェックを無効にします。空の BLOB が多く、シンボリックリンクではない SVN リポジトリを追跡する場合は、このオプションを "false" に設定します。このオプションは、git svn の実行中に変更でき、次にフェッチされるリビジョンに影響します。設定されていない場合、git svn はこのオプションが "true" であると想定します。

svn.pathnameencoding

これにより、git svn はパス名を指定されたエンコーディングに再エンコードするように指示されます。これは、Windows ユーザーや、非 UTF-8 ロケールで作業しているユーザーが、非 ASCII 文字を含むファイル名の破損を回避するために使用できます。有効なエンコーディングは、Perl の Encode モジュールでサポートされているものです。

svn-remote.<name>.automkdirs

通常、"git svn clone" および "git svn rebase" コマンドは、Subversion リポジトリにある空のディレクトリを再作成しようとします。このオプションが "false" に設定されている場合、空のディレクトリは "git svn mkdirs" コマンドが明示的に実行された場合にのみ作成されます。設定されていない場合、git svn はこのオプションが "true" であると想定します。

noMetadata、rewriteRoot、rewriteUUID、useSvnsyncProps、および useSvmProps オプションはすべて、git svn によって生成および使用されるメタデータに影響を与えるため、履歴がインポートされる前に設定ファイルで設定する必要があり、これらの設定は一度設定したら決して変更しないでください。

さらに、rewriteRoot と rewriteUUID は一緒に使用できますが、git-svn-id: メタデータ行に影響を与えるため、これらのオプションは svn-remote セクションごとに 1 つだけ使用できます。

基本的な例

Subversion 管理プロジェクトの trunk を追跡および貢献する (tags と branches は無視)

# Clone a repo (like git clone):
	git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
	cd trunk
# You should be on master branch, double-check with 'git branch'
	git branch
# Do some work and commit locally to Git:
	git commit ...
# Something is committed to SVN, rebase your local changes against the
# latest changes in SVN:
	git svn rebase
# Now commit your changes (that were committed previously using Git) to SVN,
# as well as automatically updating your working HEAD:
	git svn dcommit
# Append svn:ignore and svn:global-ignores settings to the default Git exclude file:
	git svn show-ignore >> .git/info/exclude

Subversion 管理プロジェクト全体 (trunk、tags、branches を含む) を追跡および貢献する

# Clone a repo with standard SVN directory layout (like git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Or, if the repo uses a non-standard directory layout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# View all branches and tags you have cloned:
	git branch -r
# Create a new branch in SVN
	git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
	git reset --hard svn/trunk
# You may only dcommit to one branch/tag/trunk at a time.  The usage
# of dcommit/rebase/show-ignore should be the same as above.

最初の git svn clone は非常に時間がかかる場合があります (特に大規模な Subversion リポジトリの場合)。複数のユーザー (または複数のマシンを使用する 1 人のユーザー) が git svn を使用して同じ Subversion リポジトリとやり取りしたい場合は、最初の git svn clone をサーバー上のリポジトリに対して行い、各ユーザーが git clone でそのリポジトリをクローンするようにできます。

# Do the initial import on a server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Clone locally - make sure the refs/remotes/ space matches the server
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Prevent fetch/pull from remote Git server in the future,
# we only want to use git svn for future updates
	git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
	git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and
# --stdlayout/-T/-b/-t/--prefix options as were used on server)
	git svn init http://svn.example.com/project [options...]
# Pull the latest changes from Subversion
	git svn rebase

リベース対プル/マージ

統合されていないコミットを git svn ブランチと同期するには、git pull または git merge ではなく、git svn rebase または git rebase を使用することをお勧めします。そうすることで、統合されていないコミットの履歴を上流の SVN リポジトリに対して線形に保ち、優先される git svn dcommit サブコマンドを使用して、統合されていないコミットを SVN にプッシュバックできます。

当初、git svn は開発者が git svn ブランチからプルまたはマージすることを推奨していました。これは、作成者が複数のコミットをコミットする git svn set-tree A..B 表記ではなく、単一のヘッドをコミットする git svn set-tree B を推奨していたためです。git svn set-tree A..B を使用した git pull または git merge を使用すると、SVN にコミットするときに非線形の履歴が平坦化され、マージコミットが SVN で予期せずに前のコミットを反転させる可能性があります。

マージ追跡

git svn は、標準レイアウトを採用しているリポジトリのコピー履歴 (branches と tags を含む) を追跡できますが、Git 内で発生したマージ履歴を SVN ユーザーに上流に表現することはまだできません。したがって、SVN との互換性を容易にするために、ユーザーは Git 内で履歴を可能な限り線形に保つことをお勧めします (以下の「注意点」のセクションを参照してください)。

SVN ブランチの処理

git svn が branches をフェッチするように構成されている場合 (および --follow-branches が有効な場合)、1 つの SVN ブランチに対して複数の Git ブランチを作成することがあります。追加のブランチには、branchname@nnn という形式の名前 (nnn は SVN リビジョン番号) が付けられます。これらの追加のブランチは、git svn が SVN ブランチの最初のコミットの親コミットを見つけて、ブランチを他のブランチの履歴に接続できない場合に作成されます。

通常、SVN ブランチの最初のコミットはコピー操作で構成されています。git svn はこのコミットを読み取って、ブランチが作成された SVN リビジョンを取得します。次に、この SVN リビジョンに対応する Git コミットを見つけようとし、それをブランチの親として使用します。ただし、親として機能する適切な Git コミットがない可能性があります。これは、特に、SVN ブランチが git svn によってフェッチされなかったリビジョンのコピーである場合 (たとえば、--revision でスキップされた古いリビジョンである場合)、または SVN で git svn によって追跡されないディレクトリがコピーされた場合 (たとえば、まったく追跡されないブランチや、追跡されたブランチのサブディレクトリ) に発生します。これらの場合、git svn は引き続き Git ブランチを作成しますが、既存の Git コミットをブランチの親として使用する代わりに、ブランチがコピーされたディレクトリの SVN 履歴を読み取り、適切な Git コミットを作成します。これは、「親の初期化: <ブランチ名>」というメッセージで示されます。

さらに、<branchname>@<SVN-リビジョン> という名前の特別なブランチが作成されます。ここで、<SVN-リビジョン> はブランチがコピーされた SVN リビジョン番号です。このブランチは、ブランチの新しく作成された親コミットを指します。SVN でブランチが削除され、後で別のバージョンから再作成された場合、@ が付いた複数のそのようなブランチが存在します。

これは、単一の SVN リビジョンに対して複数の Git コミットが作成される可能性があることを意味する場合があります。

例: 標準の trunk/tags/branches レイアウトを持つ SVN リポジトリでは、r.100 でディレクトリ trunk/sub が作成されます。r.200 では、trunk/sub が branches/ にコピーされて分岐されます。git svn clone -s は、ブランチ sub を作成します。また、r.100 から r.199 までの新しい Git コミットを作成し、これらをブランチ sub の履歴として使用します。したがって、r.100 から r.199 までの各リビジョンに対して 2 つの Git コミットが存在します (1 つは trunk/ を含み、もう 1 つは trunk/sub/ を含みます)。最後に、ブランチ sub の新しい親コミット (つまり、r.200 および trunk/sub/ のコミット) を指すブランチ sub@200 を作成します。

注意点

簡素化と Subversion との相互運用性のために、すべての git svn ユーザーは、SVN サーバーから直接クローン、フェッチ、dcommit を行い、Git リポジトリとブランチ間のすべての git clone/pull/merge/push 操作を回避することをお勧めします。Git ブランチとユーザーの間でコードを交換する推奨方法は、git format-patch と git am、または SVN リポジトリへの単なる 'dcommit' です。

git merge または git pull を、dcommit を計画しているブランチで実行することはお勧めしません。これは、Subversion ユーザーが作成したマージを確認できないためです。さらに、SVN ブランチのミラーである Git ブランチからマージまたはプルすると、dcommit が間違ったブランチにコミットする可能性があります。

マージする場合は、次のルールに注意してください: git svn dcommit は、次で指定された SVN コミットの上でコミットしようとします

git log --grep=^git-svn-id: --first-parent -1

したがって、dcommit するブランチの最新のコミットが、マージの最初の親であることを確認する必要があります。そうしないと、特に最初の親が同じ SVN ブランチの古いコミットである場合は、混乱が生じます。

git clone は、refs/remotes/ 階層の下のブランチ、または git svn メタデータや構成をクローンしません。したがって、git svn を使用して作成および管理されたリポジトリは、クローンを行う場合は、クローンに rsync を使用する必要があります。

dcommit は内部でリベースを使用するため、dcommit する前に git push した Git ブランチは、リモートリポジトリ上の既存の ref の強制的な上書きが必要になります。これは一般的に悪い習慣と見なされます。詳細については、git-push[1] のドキュメントを参照してください。

既に dcommit した変更に対して、git-commit[1] の --amend オプションを使用しないでください。既に他のユーザーのリモートリポジトリにプッシュしたコミットを --amend することは悪い習慣と見なされ、SVN を使用した dcommit はそれに類似しています。

SVNリポジトリをクローンする際、リポジトリレイアウトを記述するオプション（--trunk, --tags, --branches, --stdlayout）のいずれも使用しない場合、git svn clone は完全に線形の履歴を持つGitリポジトリを作成します。この場合、ブランチとタグはワーキングコピー内の別々のディレクトリとして表示されます。これは完全なリポジトリのコピーを取得する最も簡単な方法ですが、多数のブランチを持つプロジェクトでは、トランクのみの場合よりもワーキングコピーが何倍も大きくなってしまいます。したがって、標準のディレクトリ構造（trunk/branches/tags）を使用するプロジェクトでは、--stdlayoutオプションを指定してクローンすることをお勧めします。プロジェクトが標準外の構造を使用している場合、および/またはブランチやタグが不要な場合は、リポジトリレイアウトオプションを指定せずに、1つのディレクトリ（通常はトランク）のみをクローンするのが最も簡単です。ブランチとタグを含む完全な履歴が必要な場合は、--trunk / --branches / --tags オプションを使用する必要があります。

複数の --branches または --tags を使用する場合、git svn は名前の衝突を自動的に処理しません（たとえば、異なるパスの2つのブランチが同じ名前を持つ場合や、ブランチとタグが同じ名前を持つ場合）。これらの場合は、init を使用してGitリポジトリを設定し、最初の fetch の前に、$GIT_DIR/config ファイルを編集して、ブランチとタグが異なる名前空間に関連付けられるようにします。例：

branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*

構成

git svn は、[svn-remote]構成情報をリポジトリの $GIT_DIR/config ファイルに保存します。これはコアGitの[remote]セクションに似ていますが、fetch キーはglob引数を受け入れません。代わりに、branches キーと tags キーによって処理されます。一部のSVNリポジトリは、複数のプロジェクトで奇妙に構成されているため、以下に示すようなglob展開が許可されています。

[svn-remote "project-a"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	branches = branches/*/project-a:refs/remotes/project-a/branches/*
	branches = branches/release_*:refs/remotes/project-a/branches/release_*
	branches = branches/re*se:refs/remotes/project-a/branches/*
	tags = tags/*/project-a:refs/remotes/project-a/tags/*

ローカル参照（: の右側）の*（アスタリスク）ワイルドカードは必ずパスの最も右側のコンポーネントである必要があることに注意してください。ただし、リモートワイルドカードは、独立したパスコンポーネント（/ または EOL で囲まれている）である限り、どこにあっても構いません。このタイプの構成は、init によって自動的に作成されることはなく、テキストエディターまたは git config を使用して手動で入力する必要があります。

また、1つの単語につき1つのアスタリスクのみが許可されていることに注意してください。例：

branches = branches/re*se:refs/remotes/project-a/branches/*

release、rese、re123se のブランチと一致しますが、

branches = branches/re*s*e:refs/remotes/project-a/branches/*

エラーが発生します。

中括弧内にカンマ区切りの名前リストを使用することで、ブランチまたはタグのサブセットをフェッチすることもできます。例：

[svn-remote "huge-project"]
	url = http://server.org/svn
	fetch = trunk/src:refs/remotes/trunk
	branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
	tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

複数の fetch、branches、および tags キーがサポートされています。

[svn-remote "messy-repo"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
	branches = branches/server/*:refs/remotes/project-a/branches/*
	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
	tags = tags/server/*:refs/remotes/project-a/tags/*

このような構成でブランチを作成するには、-d または --destination フラグを使用して、使用する場所を明確にする必要があります。

$ git svn branch -d branches/server release-2-3-0

git-svn は、ブランチまたはタグが表示された最も高いリビジョンを追跡していることに注意してください。フェッチ後にブランチまたはタグのサブセットが変更された場合は、$GIT_DIR/svn/.metadata を手動で編集して、必要に応じて branches-maxRev および/または tags-maxRev を削除（またはリセット）する必要があります。

ファイル

$GIT_DIR/svn/**/.rev_map.*

Subversionのリビジョン番号とGitのコミット名の間のマッピング。noMetadataオプションが設定されていないリポジトリでは、すべてのコミットの末尾にある git-svn-id: 行から再構築できます（詳細については、上記のsvn.noMetadataセクションを参照）。

git svn fetch および git svn rebase は、rev_map が存在しない場合、または最新でない場合に自動的に更新します。git svn reset は自動的に巻き戻します。

バグ

svn:executable を除くすべてのSVNプロパティを無視します。処理されないプロパティは、$GIT_DIR/svn/<refname>/unhandled.log に記録されます。

名前が変更されたディレクトリとコピーされたディレクトリはGitによって検出されないため、SVNにコミットするときに追跡されません。すべての可能なコーナーケースで動作するようにするのは非常に困難で時間がかかるため（Gitもそうではありません）、これに対するサポートを追加する予定はありません。名前が変更されたファイルとコピーされたファイルが、Gitで検出できる程度に類似している場合は、コミットが完全にサポートされます。

SVNでは、（推奨されていませんが）タグへの変更をコミットすることが可能です（タグは単なるディレクトリコピーであるため、技術的にはブランチと同じです）。SVNリポジトリをクローンするとき、git svn は将来タグへのこのようなコミットが発生するかどうかを知ることができません。したがって、保守的に動作し、すべてのSVNタグをブランチとしてインポートし、タグ名の前に tags/ を付けます。

参考

git-rebase[1]

GIT

git[1] スイートの一部

scroll-to-top