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

git svnは、SubversionとGit間の変更セットのシンプルな導管です。これは、SubversionとGitリポジトリ間で変更の双方向フローを提供します。

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

Subversionリポジトリを追跡した（上記いずれかの方法で）後、GitリポジトリはfetchコマンドによってSubversionから更新され、SubversionはdcommitコマンドによってGitから更新されます。

noMetadata、rewriteRoot、rewriteUUID、useSvnsyncProps、useSvmPropsの各オプションは、すべてgit svnによって生成および使用されるメタデータに影響するため、履歴がインポートされる前に設定ファイルに設定されなければなりません。また、これらの設定は一度設定されたら決して変更してはなりません。

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

Subversion管理プロジェクトのトランクを追跡し、貢献する（タグとブランチは無視）

Subversion管理プロジェクト全体を追跡し、貢献する（トランク、タグ、ブランチを含む）

最初のgit svn cloneはかなりの時間を要する可能性があります（特に大規模なSubversionリポジトリの場合）。複数の人（または複数のマシンを持つ1人）が同じSubversionリポジトリと対話するためにgit svnを使用したい場合、サーバー上のリポジトリに最初のgit svn cloneを実行し、各人がgit cloneでそのリポジトリをクローンすることができます。

未統合のコミットを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 pullまたはgit mergeをgit svn set-tree A..Bとともに使用すると、SVNにコミットする際に非線形履歴がフラット化され、これによりマージコミットがSVNの以前のコミットを予期せず逆転させる可能性があります。

git svnは、標準レイアウトを採用するリポジトリのコピー履歴（ブランチやタグを含む）を追跡できますが、Git内で発生したマージ履歴をSVNユーザーにアップストリームに表現することはまだできません。したがって、SVNとの互換性を容易にするために、Git内で履歴を可能な限り線形に保つことが推奨されます（以下のCAVEATSセクションを参照）。

git svnがブランチをフェッチするように設定されており（かつ--follow-branchesが有効になっている場合）、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までの各リビジョン（trunk/を含むものとtrunk/sub/を含むもの）には2つのGitコミットが存在することになります。最後に、ブランチ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コミットの上にコミットしようとします。

したがって、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/branches/tags）を使用するプロジェクトの場合は、--stdlayoutオプションを使用してクローンすることをお勧めします。プロジェクトが非標準の構造を使用している場合、および/またはブランチとタグが不要な場合は、リポジトリレイアウトオプションを指定せずに1つのディレクトリ（通常はtrunk）のみをクローンするのが最も簡単です。ブランチとタグを含む完全な履歴が必要な場合は、--trunk / --branches / --tagsオプションを使用する必要があります。

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

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

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

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

はブランチrelease、rese、re123seに一致しますが、

はエラーを生成します。

中括弧内に名前をコンマ区切りでリストすることで、ブランチまたはタグのサブセットをフェッチすることも可能です。たとえば、

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

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

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

svn:executable以外のすべてのSVNプロパティは無視されます。未処理のプロパティは$GIT_DIR/svn/<refname>/unhandled.logに記録されます。

名前変更されたディレクトリやコピーされたディレクトリはGitによって検出されないため、SVNへのコミット時に追跡されません。これは非常に難しく、考えられるすべてのコーナーケースで機能させるには時間がかかるため、サポートを追加する予定はありません（Git自身もこれを行いません）。名前変更されたファイルやコピーされたファイルのコミットは、Gitがそれらを検出するのに十分類似していれば完全にサポートされます。

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

git-rebase[1]

git[1]スイートの一部