セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
- 2.47.1 → 2.50.1 変更なし
-
2.47.0
2024-10-06
- 2.44.1 → 2.46.4 変更なし
-
2.44.0
2024-02-23
- 2.35.1 → 2.43.7 変更なし
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 変更なし
- 2.34.0 変更なし
- 2.32.1 → 2.33.8 変更なし
-
2.32.0
2021-06-06
- 2.30.1 → 2.31.8 変更なし
-
2.30.0
2020-12-27
- 2.25.1 → 2.29.3 変更なし
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 変更なし
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 変更なし
-
2.22.0
2019-06-07
- 2.19.1 → 2.21.4 変更なし
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 変更なし
-
2.18.0
2018-06-21
- 2.16.6 → 2.17.6 変更なし
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
- 2.12.5 → 2.13.7 変更なし
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
- 2.6.7 → 2.7.6 変更なし
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
- 2.3.10 変更なし
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
説明
git svn は、SubversionとGitの間で変更セットをやり取りするためのシンプルなパイプ役です。SubversionとGitリポジトリ間で変更を双方向に流すことができます。
git svn は、--stdlayout オプションを使用することで、一般的な「trunk/branches/tags」レイアウトを持つ標準的なSubversionリポジトリを追跡できます。また、-T/-t/-b オプションを使用して、任意のレイアウトのブランチやタグを追跡することもできます (以下の init のオプション、および clone コマンドを参照)。
Subversionリポジトリを追跡すると (上記のいずれかの方法で)、fetch コマンドでGitリポジトリを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 オプションを設定します。このオプションは推奨されません。このオプションを使用する前に、このmanページの 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, plain svn) の場合、ユーザー名を指定します。他のトランスポート (例:
svn+ssh://
) の場合、URLにユーザー名を含める必要があります。例:svn+ssh://foo@svn.bar.com/project
- --prefix=<prefix>
-
これは、trunk/branches/tags が指定されている場合に、リモートの名前に付加されるプレフィックスを指定することを可能にします。プレフィックスには自動的に末尾のスラッシュは含まれないため、必要であれば引数に含めるようにしてください。--branches/-b が指定されている場合、プレフィックスには末尾のスラッシュを含める必要があります。いずれの場合も、プレフィックス (末尾のスラッシュ付き) を設定することを強く推奨します。これにより、SVN追跡refは "refs/remotes/$prefix/**" に配置され、これはGit自身のリモート追跡refレイアウト (refs/remotes/$remote/**) と互換性があります。プレフィックスの設定は、共通のリポジトリを共有する複数のプロジェクトを追跡したい場合にも役立ちます。デフォルトでは、プレフィックスは origin/ に設定されています。
注Git v2.0以前では、デフォルトのプレフィックスは "" (プレフィックスなし) でした。これは、SVN追跡refが "refs/remotes/*" に配置され、Git自身のリモート追跡refの編成方法と互換性がなかったことを意味します。古いデフォルトを維持したい場合は、コマンドラインで --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
オプションは、特定のレポジトリでのすべての fetch (clone、dcommit、rebase などによる自動フェッチを含む) に対して一致する必要があります。config key: svn-remote.<name>.ignore-paths
ignore-paths設定キーが設定されており、コマンドラインオプションも指定されている場合、両方の正規表現が使用されます。
例
- --include-paths=<regex>
-
これにより、SVNからのチェックアウトから一致するパスのみを含めるPerl正規表現を指定できます。
--include-paths
オプションは、特定のレポジトリでのすべての fetch (clone、dcommit、rebase などによる自動フェッチを含む) に対して一致する必要があります。--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にコミットされていない) 作業をそれに対してリベースします。
これは
svn
update
または git pull と同様に機能しますが、git svn でdcommitしやすいように git merge ではなく git rebase でリニアな履歴を保持します。これは、git svn fetch と git rebase が受け入れるすべてのオプションを受け入れます。ただし、
--fetch-all
は現在の [svn-remote] からのみフェッチし、すべての [svn-remote] 定義からはフェッチしません。git rebase と同様に、これはワーキングツリーがクリーンであり、コミットされていない変更がないことを必要とします。
これにより、必要に応じてrev_mapが自動的に更新されます (詳細は、以下の FILES セクションの $GIT_DIR/svn/**/.rev_map.* を参照してください)。
- dcommit
-
現在のブランチからの各diffをSVNリポジトリに直接コミットし、その後リベースまたはリセットします (SVNとheadの間にdiffがあるかどうかに応じて)。これにより、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 設定キーの 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にプッシュされている非fast-forwardマージを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> は、ブランチまたはタグを作成するために使用するパスを指定し、設定されたブランチまたはタグのリフスペックの左側のパターンと一致する必要があります。これらのリフスペックは、以下のコマンドで確認できます。
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」の以下の機能がサポートされています
新機能
注SVN自体はUTCの時刻しか保存せず、他には何も保存しません。通常のsvnクライアントはUTC時刻を現地時刻に変換します (またはTZ=環境変数に基づきます)。このコマンドも同じ動作をします。 その他の引数は git log に直接渡されます。
- blame
-
ファイルの各行を最後に変更したリビジョンと作者を表示します。このモードの出力は、デフォルトで「svn blame」の出力とフォーマット互換です。SVN blame コマンドと同様に、ワーキングツリー内のローカルのコミットされていない変更は無視されます。HEADリビジョン内のファイルのバージョンが注釈付けされます。不明な引数は git blame に直接渡されます。
- find-rev
-
rN の形式のSVNリビジョン番号が与えられた場合、対応するGitコミットハッシュを返します (これは、どのブランチを検索するかを指定するために、オプションでツリーイッシュが続く場合があります)。ツリーイッシュが与えられた場合、対応するSVNリビジョン番号を返します。
- set-tree
-
このコマンドの代わりに dcommit の使用を検討してください。指定されたコミットまたはツリーオブジェクトをSVNにコミットします。これは、インポートされたフェッチデータが最新であることに依存します。SVNにコミットする際にパッチを適用する試みは一切行いません。ツリーまたはコミットで指定されたものでファイルを上書きするだけです。すべてのマージは、git svn 機能とは独立して行われたものと見なされます。
- create-ignore
-
ディレクトリの svn:ignore および svn:global-ignores プロパティを再帰的に検索し、一致する .gitignore ファイルを作成します。作成されたファイルはコミットするためにステージングされますが、コミットはされません。特定のリビジョンを参照するには -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 設定ファイルオプションを参照してください。)
- commit-diff
-
コマンドラインからの2つのツリーイッシュ引数の差分をコミットします。このコマンドは、
git
svn
init
されたリポジトリ内にいることに依存しません。このコマンドは3つの引数を取ります。(a) 比較元の元のツリー、(b) 新しいツリー結果、(c) ターゲットSubversionリポジトリのURL。git svn を認識するリポジトリ (git svn でinit
されたもの) で作業している場合、最後の引数 (URL) は省略できます。このためには -r<revision> オプションが必要です。コミットメッセージは、
-m
または-F
オプションで直接提供されるか、2番目のツリーイッシュがそのようなオブジェクトを示す場合はタグまたはコミットから間接的に提供されるか、またはエディタを呼び出して要求されます (以下の--edit
オプションを参照)。 - info
-
「svn info」が提供するものと同様に、ファイルまたはディレクトリに関する情報を表示します。現時点では -r/--revision 引数はサポートしていません。URL: フィールドの値のみを出力するには --url オプションを使用します。
- proplist
-
指定されたファイルまたはディレクトリに関するSubversionリポジトリに保存されているプロパティをリスト表示します。特定のリビジョンを参照するには -r/--revision を使用します。
- propget
-
最初の引数として与えられたSubversionプロパティをファイルに対して取得します。特定のリビジョンは -r/--revision で指定できます。
- propset
-
最初の引数として与えられたSubversionプロパティを、2番目の引数として与えられた値に、3番目の引数として与えられたファイルに対して設定します。
例
git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile
これは、ファイル devel/py-tipper/Makefile に対してプロパティ svn:keywords を FreeBSD=%H に設定します。
- show-externals
-
Subversionの外部定義を表示します。特定のリビジョンを指定するには -r/--revision を使用します。
- gc
-
$GIT_DIR/svn/<refname>/unhandled.log ファイルを圧縮し、$GIT_DIR/svn/<refname>/index ファイルを削除します。
- reset
-
fetch の効果を、指定されたリビジョンまで元に戻します。これにより、SVNリビジョンを再 fetch できます。通常、SVNリビジョンの内容は変更されるべきではなく、reset は必要ありません。ただし、SVNの権限が変更された場合、または --ignore-paths オプションを変更した場合、fetch が「not found in commit」(以前はファイルが見えなかった) または「checksum mismatch」(変更を見逃した) で失敗する可能性があります。問題のあるファイルを ( --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
オプション
- --template=<template-directory>
-
init コマンドでのみ使用されます。これらは git init に直接渡されます。
- -r <arg>
- --revision <arg>
-
fetch コマンドで使用します。
これにより、部分的な/切断された履歴のリビジョン範囲がサポートされます。$NUMBER、$NUMBER1:$NUMBER2 (数値範囲)、$NUMBER:HEAD、BASE:$NUMBER のすべてがサポートされます。
これにより、フェッチ実行時に部分的なミラーを作成できますが、履歴がスキップされ失われるため、一般的には推奨されません。
- -
- --stdin
-
set-tree コマンドでのみ使用されます。
標準入力からコミットのリストを読み込み、逆順にコミットします。各行から先頭の 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 <>」の形式の1行を返すことが期待され、これは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 を参照)、dcommit を使用する際に git rebase に直接渡されます。
- -n
- --dry-run
-
これは dcommit、rebase、branch、および tag コマンドで使用できます。
dcommit の場合、SVNにコミットされる差分を表示するGit引数のシリーズを出力します。
rebase の場合、現在のブランチに関連付けられたアップストリームSVNリポジトリに関連付けられたローカルブランチと、フェッチ元のSVNリポジトリのURLを表示します。
branch および tag の場合、ブランチまたはタグの作成時にコピーに使用されるURLを表示します。
- --use-log-author
-
svnコミットをGitに取得する際 (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を追跡する際に、デフォルトのリファレンス名を上書きしてフェッチできます。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
-
これにより、git svn は、SVN::Mirror (またはsvk) を使用して作成されたミラーからリポジトリのURLとUUIDをメタデータ用に再マッピングできます。
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からリポジトリを作成できます。たとえば、管理者はサーバー上でローカルに git svn を実行し (file:// 経由でアクセス)、メタデータに公開の 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にチェックインされた壊れたシンボリックリンクの回避策として、潜在的にコストのかかるチェックを無効にします。シンボリックリンクではない多くの空のブロブを持つSVNリポジトリを追跡している場合は、このオプションを「false」に設定します。このオプションは git svn の実行中に変更でき、次のフェッチされたリビジョンに影響します。設定されていない場合、git svn はこのオプションを「true」と仮定します。
- svn.pathnameencoding
-
これは、git svnにパス名を指定されたエンコーディングに再コーディングするように指示します。Windowsユーザーや非UTF8ロケールで作業するユーザーが、非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を追跡し、貢献する (タグとブランチは無視)
# 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
表記よりも、単一のHEADをコミットする git
svn
set-tree
B
を好んだためです。git
svn
set-tree
A..B
で git pull または git merge を使用すると、SVNにコミットするときに非線形履歴が平坦化され、マージコミットがSVNの以前のコミットを予期せず元に戻す可能性があります。
マージの追跡
git svn は、標準的なレイアウトを採用しているリポジトリのコピー履歴 (ブランチやタグを含む) を追跡できますが、Git内で発生したマージ履歴をSVNユーザーにアップストリームに戻すことはまだできません。したがって、SVNとの互換性を容易にするために、Git内では履歴を可能な限り直線的に保つことをお勧めします (以下の CAVEATS セクションを参照)。
SVNブランチの扱い
git svn がブランチをフェッチするように設定されており (--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コミットを作成します。これは「Initializing parent: <branchname>」というメッセージで示されます。
さらに、<branchname>@<SVN-Revision> という特殊なブランチが作成されます。ここで <SVN-Revision> は、ブランチがコピーされた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@200 を作成し、ブランチ sub の新しい親コミット (つまり、r.200 と trunk/sub/ のコミット) を指します。
注意点
単純化のため、およびSubversionとの相互運用のために、すべての git svn ユーザーはSVNサーバーから直接クローン、フェッチ、およびdcommitし、Gitリポジトリとブランチ間のすべての git clone/pull/merge/push 操作を避けることをお勧めします。Gitブランチとユーザー間でコードを交換する推奨される方法は git format-patch と git am、または単にSVNリポジトリへの 'dcommit' です。
dcommit を行う予定のブランチで git merge または git pull を実行することは推奨されません。なぜなら、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 ブランチは、リモートリポジトリ上の既存の参照を強制的に上書きする必要があります。これは一般的に悪い慣習と見なされているため、詳細は git-push[1] ドキュメントを参照してください。
すでに dcommit した変更に対して git-commit[1] の --amend オプションを使用しないでください。他のユーザーのためにすでにリモートリポジトリにプッシュしたコミットを --amend することは悪い慣習とされており、SVNでの dcommit もそれに相当します。
SVNリポジトリをクローンする際、リポジトリレイアウトを記述するオプション (--trunk, --tags, --branches, --stdlayout) が使用されていない場合、git svn clone は完全に線形な履歴を持つGitリポジトリを作成し、ブランチとタグは作業コピーの別々のディレクトリとして表示されます。これは完全なリポジトリのコピーを取得する最も簡単な方法ですが、多くのブランチを持つプロジェクトの場合、trunkのみの場合よりも何倍も大きな作業コピーになります。したがって、標準的なディレクトリ構造 (trunk/branches/tags) を使用するプロジェクトの場合、--stdlayout
オプションを使用してクローンすることをお勧めします。プロジェクトが非標準的な構造を使用している場合、および/またはブランチとタグが不要な場合は、リポジトリレイアウトオプションを指定せずに1つのディレクトリ (通常はtrunk) のみをクローンするのが最も簡単です。ブランチとタグを含む完全な履歴が必要な場合は、--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 キーはグロブ引数を受け入れず、代わりに branches および tags キーによって処理されます。一部のSVNリポジトリは、複数のプロジェクトで奇妙に設定されているため、以下に示すようなグロブ展開が許可されています。
[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 を適切に削除 (またはリセット) する必要があります。
バグ
svn:executable 以外のすべてのSVNプロパティは無視します。未処理のプロパティは $GIT_DIR/svn/<refname>/unhandled.log にログ記録されます。
名前変更およびコピーされたディレクトリはGitによって検出されず、SVNにコミットする際に追跡されません。すべての可能なエッジケースで機能するようにするのは非常に難しく時間がかかるため、これに対するサポートを追加する予定はありません (Gitもこれを行いません)。Gitが検出できるほど似ていれば、名前変更およびコピーされたファイルのコミットは完全にサポートされます。
SVNでは、タグに変更をコミットすることが可能ですが (推奨されません)、git svn はSVNリポジトリをクローンする際に、そのようなコミットが将来発生するかどうかを知ることができません。そのため、控えめにSVNタグをすべてブランチとしてインポートし、タグ名に tags/ をプレフィックスとして付けます。
GIT
git[1]スイートの一部