サーチ…
備考
非常に大きなSVNリポジトリのクローン作成
git-svnがSVNリポジトリの完全な履歴を再構築する必要があるため、SVNリポジトリ履歴が本当に大きければ、この操作に数時間かかることがあります。幸いにもSVNリポジトリを一度クローンするだけで済みます。他のgitリポジトリと同様に、repoフォルダを他の共同編集者にコピーすることもできます。複数のコンピュータにフォルダをコピーすると、大きなSVNリポジトリを最初からクローン作成するだけですばやくできます。
コミットとSHA1について
git svn dcommitコマンドを使用すると、ローカルのgitコミットが書き換えられます。このコマンドは、SVNサーバーで作成されたSVNリビジョンを参照するgit commitメッセージにテキストを追加します。これは非常に便利です。しかし、新しいテキストを追加するには、実際には実行できない既存のコミットのメッセージを変更する必要があります。gitコミットは変更できません。解決策は、同じ内容と新しいメッセージで新しいコミットを作成しますが、技術的には新しいコミットです（つまり、git commitのSHA1が変更されます）
git-svnのために作成されたgitコミットはローカルなので、gitコミットのSHA1 idsは各gitリポジトリごとに異なります！つまり、SHA1を使って他の人からのコミットを参照することはできません。同じコミットでは、それぞれのローカルgitリポジトリに異なるSHA1があるからです。リポジトリの異なるコピー間でコミットを参照する場合は、SVNサーバーにプッシュするときにコミットメッセージに追加されたsvnリビジョン番号に依存する必要があります。
SHA1をローカル操作に使用することもできます（特定のコミット、チェリーピックおよびリセットなどの表示/差分）
トラブルシューティング
git svn rebaseコマンドがチェックサムの不一致エラーを発行する
コマンドgit svn rebaseは、次のようなエラーを送出します。
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
この問題の解決策は、問題のファイルが最後に修正されたときにsvnをリビジョンにリセットし、git svnをフェッチしてSVN履歴を復元することです。 SVNリセットを実行するコマンドは次のとおりです。
- git log -1 -
<path_to_file>（コミットメッセージに表示されるSVNリビジョン番号をコピーします） - git svn reset
<revision_number> - git svn fetch
あなたは再びSVNからデータをプッシュ/プルできるはずです
ファイルがコミットに見つかりませんでした SVNからフェッチまたはプルしようとすると、次のようなエラーが表示されます
<file_path> was not found in commit <hash>
これは、SVNのリビジョンが何らかの理由でローカルコピーに存在しないファイルを変更しようとしていることを意味します。このエラーを取り除く最善の方法は、ファイルのパスを無視してフェッチを強制し、最新のSVNリビジョンのステータスに更新します：
-
git svn fetch --ignore-paths <file_path>
SVNリポジトリのクローニング
このコマンドでリポジトリの新しいローカルコピーを作成する必要があります
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
あなたのSVNリポジトリが標準レイアウト（トランク、ブランチ、タグフォルダ）に従っているなら、いくつかのタイプを保存することができます：
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn cloneは、各SVNリビジョンを1つずつチェックアウトし、履歴を再作成するためにローカルリポジトリでgit commitを行います。 SVNリポジトリに多くのコミットがある場合、これにはしばらく時間がかかります。
コマンドが終了すると、SVNリポジトリのトランクブランチを追跡するmasterというローカルブランチを持つ完全なgitリポジトリが作成されます。
SVNから最新の変更を取得する
git pull相当するのはコマンドです
git svn rebase
これにより、SVNリポジトリからのすべての変更が取得され、現在のブランチのローカルコミットの上に適用されます。
このコマンドを使用することもできます
git svn fetch
SVNリポジトリから変更を取得してローカルマシンに持ち込みますが、ローカルブランチには適用しません。
ローカル変更をSVNにプッシュする
コマンド
git svn dcommit
あなたのローカルgitコミットごとにSVNリビジョンを作成します。 SVNと同様に、ローカルのgitの履歴はSVNリポジトリの最新の変更と同期している必要があります。コマンドが失敗した場合は、最初にgit svn rebase実行してみてください。
ローカルで働く
通常のgitコマンドで、ローカルのgitリポジトリを通常のgitリポジトリとして使用してください：
-
git add FILEとgit checkout -- FILEをステージング/アンステージする -
git commit変更を保存します。これらのコミットはローカルになり、通常のgitリポジトリと同様にSVNリポジトリに「プッシュ」されません -
git stashとgit stash popスタッシュを使用できるようにする -
git reset HEAD --hardあなたのすべてのローカルな変更を元に戻す -
git logリポジトリ内のすべての履歴にアクセスする -
git rebase -iあなたの地域の歴史を自由に書き換えることができます -
git branchとgit checkoutを使ってローカルブランチを作成する
git-svnのドキュメントでは「SubversionはGitよりははるかに洗練されていないシステムです」と述べているので、Subversionサーバーの履歴を乱すことなくgitの機能をすべて使用することはできません。幸いにも、ルールは非常に単純です： 履歴を線形に保つ
これは、ほぼすべてのGitの操作を行うことができます意味：枝を作成、削除/並べ替え/コミットを潰し、コミットを削除し、周りの歴史を動かす、など何でもなく、マージ 。ローカルブランチの履歴を再統合する必要がある場合は、代わりにgit rebase使用してください。
マージを実行すると、マージコミットが作成されます。マージコミットに関する特別なことは、それらが2つの親を持ち、それが履歴を非線形にすることです。非線形履歴は、あなたがリポジトリにマージコミットを「プッシュ」する場合にSVNを混乱させます。
しかし、心配しないでください： git merge commitをSVNに「プッシュ」すると、何も破壊されません 。そうすると、git mergeコミットがsvnサーバーに送信されると、そのマージのすべてのコミットのすべての変更が含まれます。そのため、コミットの履歴は失われますが、コードの変更は失われます。
空のフォルダの処理
gitはフォルダの概念を認識せず、ファイルとそのファイルパスで動作します。つまり、gitは空のフォルダを追跡しません。しかし、SVNはそうです。 git-svnを使うと、デフォルトでgitで空のフォルダを変更するとSVNに伝播しません 。
コメントを発行するときに--rmdirフラグを使用すると、この問題が修正され、SVN内の最後のファイルをローカルに削除するとSVNの空のフォルダが削除されます。
git svn dcommit --rmdir
残念ながら、既存の空のフォルダは削除されません 。手動で行う必要があります 。
dcommitを実行するたびにフラグを追加しないようにするには、git GUIツール（SourceTreeなど）を使用している場合に安全に再生するには、次のコマンドを使用してこの動作をデフォルトとして設定します。
git config --global svn.rmdir true
これにより、.gitconfigファイルが変更され、次の行が追加されます。
[svn]
rmdir = true
SVNのために空のままにしておく必要がある、すべてのuntrackedファイルとフォルダを削除するには、gitコマンドを使います：
git clean -fd
注意してください：前のコマンドは、すべての未追跡のファイルと空のフォルダ、SVNで追跡する必要があるものを削除します！あなたがSVNによって追跡された空のフォルダを生成する必要があるなら、コマンドを使用してください
git svn mkdirs
これは、トラッキングされていないファイルやフォルダからワークスペースをクリーンアップする場合は、SVNが追跡する空のフォルダを再作成するために常に両方のコマンドを使用する必要があることを意味します。
git clean -fd && git svn mkdirs