[解決済み] Google CodeのSubversionリポジトリをGitHubにフォークして同期させる

質問

書き込み権限のない Google Code の Subversion リポジトリを GitHub リポジトリにフォークして同期させるにはどうしたらよいでしょうか。

自分のGitリポジトリで自分の機能を開発できるようにしたいのですが、Google Code Subversionリポジトリに対しても同期させたいと思っています。Google Codeプロジェクト側からの修正を取得するためです。

私は git-svn について知っており、私が完全に制御している Subversion リポジトリのアップストリームとダウンストリームに以前それを使用しました。しかし、Google Code Subversion リポジトリと同期させる方法を知りません。

どのように解決するのですか？

git-svn からのリモートブランチは、通常の Git リモートとほとんど同じです。ですから、あなたのローカルリポジトリでは、git-svn クローンを持ち、変更を GitHub にプッシュすることができます。Gitは気にしません。git-svn クローンを作成し、まったく同じ変更を GitHub にプッシュすれば、Google Code リポジトリの非公式ミラーができあがります。あとはバニラGitです。

git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master

これで、Subversion のリポジトリと Git を同期させることができるようになりました。それは次のようなものでしょう。

git svn rebase
git push

gitkなどでは、このようになります。

o [master][remotes/trunk][remotes/origin/master]
|
o
|
o

そして git svn rebase を実行すると、このようになります。

o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o

ということで、今度は git push を実行すると、これらのコミットが GitHub にプッシュされます。 [remotes/origin/master] となります。 というブランチを作成します。そして、最初のアスキーアートダイアグラムのシナリオに戻ることになるのです。

問題は、自分の変更をどのようにミックスするかです。つまり、git-svn-rebase や git-push を行っている同じブランチにはコミットしないということです。自分の変更には別のブランチが必要です。そうしないと、Subversion の変更の上に自分の変更を重ねることになり、Git リポジトリをクローンしている人を怒らせてしまうかもしれません。フォローする? では、ブランチを作成し、それを "features" と呼ぶことにしましょう。そして、features ブランチにコミットして GitHub にプッシュします。あなたの gitk はこのようになります。

o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o

ここで features ブランチは Google Code ブランチより数コミット進んでいますね？では、Google Code から新しいものを取り込みたい場合はどうすればいいのでしょうか? その場合は git svn rebase を最初に実行して、このようになります。

                           o [features][remotes/origin/features]
[master][remotes/trunk] o  |
                        |  o
                        o /
                        |/
                        o[remotes/origin/master]
                        |
                        o

もし、あなたが git push のマスターアウトを想像してください。 [リモコン/オリジン/マスター] を は master と同じ地点にあると想像できます。しかし、feature ブランチにはその変更が反映されていません。そこで、master を feature にマージするか、feature をリベースするかのどちらかを選択することになります。マージは次のようになります。

git checkout features
git merge master 

            o [features]
           /|
          / o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

次に、GitHubに機能をプッシュします。スペースを節約するためにmasterのリモートは省きましたが、それらは以下のように同じポイントになります。 [master] と同じ位置になります。 .

リベースの方法は少し悪質です。あなたのプッシュは fast-forward マージではないので、-force でプッシュしなければなりません (featuresブランチをクローンした人の下から引き抜くことになります)。これをやってもいいとは思われていませんが、あなたが決心すれば誰もそれを止めることはできません。例えば、パッチが少し手直しされた形でアップストリームに受け入れられたときなど、いくつかのことがより簡単になります。コンフリクトに悩まされることもないし、上流のパッチをリベース - スキップすればいいだけだからです。とにかく、リベースは次のようなものです。

git rebase master features

         o [features]
         |
         o
         |  o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

そして、その後に git push --force というもの。無理にやる必要があるのはおわかりでしょう、歴史では大昔の分裂から [リモート/オリジン/フィーチャー]。 から新しい現在のポストリベースである [機能] に変更します。 .

これはすべて動作しますが、多くの労力を必要とします。もしあなたが定期的に貢献するつもりなら、最善の策はしばらくの間このように作業し、いくつかのパッチを上流に送り、Subversion へのコミットアクセスを得られるかどうかを確認することでしょう。そうでない場合は、GitHub に変更を書き込まないようにしましょう。ローカルにとどめておいて、とにかく上流で受け入れられるように努力しましょう。