33

Web上で「svnからgitへの移行」やその他の「git-svnワークフロー」の記事をたくさん読んだことがありますが、それでも、過度に単純な状況を扱っていることが多いと思います。多くの場合、git-svnを使用してsvnリポジトリのクローンを作成する複数の開発者間で、pull、fetch、mergeなどのgitのフルパワーを使用せずに、gitを使用してローカルでハックしたい人を対象としています。それでも、変更をいつでも（公式の）svnリポジトリにプッシュして、gitでの作業に戻り、内容を共有できることなどを期待しています。

これらの記事で、純粋なgitで行うすべてのことを実行できないことを認めるときはいつでも、結果と起こりうる混乱が明確に説明されることはありません（または、それは私だけですか？）。git-svnのマニュアルページでさえ警告について言及していますが、実際には広範囲にわたるものではありません。

私が読んだことによると、git-svnをその特定の方法で使用すると、問題が発生する可能性があると感じています。これについては、以下で説明します。私がこれについて正しいかどうか誰かに教えてもらえますか？

これが物事を行うための「望まれる」方法です：

  1. svnリポジトリにプロジェクトがあります
  2. 開発者git-svn-cloneはsvnリポジトリです。彼はローカルで物事をハックし始めます
  3. 開発者Bgit-svn-cloneは同じsvnリポジトリです。彼は自分で物事をハックし始めます。
  4. しばらくの間それを行い、おそらく開発者C / D / ...を追加し、元のリポジトリに「標準」のsvnコミットを行う他の開発者がいると、gitユーザーはコードを共有してあらゆる種類のgitマジックを実行したいと思うでしょう。 。
  5. これらのgitユーザーのいずれかが、マージされた変更をsvn（dcommit？）にプッシュできるようにしたいと考えています。

私の質問は：私は夢を見ていますか？少し前に読んだのですが、gitの本で、git-svn-cloneはもちろんsvnリポジトリの「ミラー」であるgitリポジトリを作成できますが、異なる開発者によってそのように作成されたgitリポジトリは異なる」 ids」とコミットは異なるハッシュを持ちます。したがって、私の理解では、これらのgitリポジトリは共通のgit祖先を共有しないため、共有、マージなどに必要なすべてのgitコマンドを使用することはできません。それは本当ですか、このワークフローで問題に直面するのでしょうか？

時々私はこれが少なくとも「公式の」裸のgitリポジトリを使用して行われる可能性があることを読みました。それはgit-svn-clonedされる唯一のものであり、すべてのgitユーザーはこれから始めなければなりません。次に、この中央のgitリポジトリを担当し、すべてをsvnリポジトリにコミットする前に、gitdev間の変更を収集する人が必要です。これは、gitユーザーが元のgitリポジトリがsvnからのものであることを「認識」せず、すべてのgitコマンドを好きなように使用できるようにする唯一の方法です。gitとsvnの両方に堪能である必要がある（そしてgit-svnの警告について知っている）必要があるのは、「マージマネージャー」（または彼が呼んでいるもの）だけです。

私はgit-svnの警告を完全に誤解していますか？これを行う簡単な方法はありますか？

4

7 に答える 7

23

私は最近これをたくさん実験していて、なんとかうまくいくセットアップを思いついたと思います。はい、それは厳密なリベースのみの体制です、はい、それは複雑ですが、ローカルで作業するためにGitを使用することができます（速度、履歴、隠し場所、インデックスなど）。

チーム内の他のGitユーザーとコラボレーションするときに、舞台裏でブランチを使用できると思いますが、これについては個人的にあまり実験していません。コミットする前にログを線形化する限り、それは機能するはずです。

これが短いバージョンです（すでに言われたことをたくさん繰り返します）：

  1. Subversionリポジトリを中央サーバーの「フェッチ」リポジトリに複製します
  2. 同じサーバーで「ベア」リポジトリを初期化する
  3. fecthingレポジトリからベアレポジトリにプッシュします
  4. 開発者にベアリポジトリのクローンを作成してもらい、次に
    1. git svn init svnurlgit-svnリモートを設定するには、
    2. git update-ref refs/remotes/git-svn refs/remotes/origin/masterしたがって、git-svnにはリビジョンへのポインタがあります
  5. 自動的に（コミットフック）「フェッチ」リポジトリsvnリベースを取得し、ベアリポジトリにプッシュします
  6. 開発者は、裸のリポジトリからプルしますgit pull --rebase
  7. SVNからの新しいリビジョンの場合、最初に実行している開発者git svn dcommitは上記を繰り返す必要があります。update-ref

このページにはワークフローの図があります（画像をインライン化する前に、より多くのレピュテーションポイントが必要です）。更新：ここに行きます：

于 2010-08-06T09:15:09.867 に答える
19

もちろん問題はステップ4です。dcommitは、ローカル履歴をサーバーに再生しようとします。Dcommitは、あなたがSVNクライアントであるかのように見せかけます。さて、あなたがコミットしているコードがあなただけのものではない場合、それはSVNにコミットするのが難しいものです。

教祖がこの問題について書いていることは次のとおりです。

  • 単純化とSVNとの相互運用のために、すべてのgit-svnユーザーがSVNサーバー（つまりリモートSVNリポジトリ）から直接クローン、フェッチ、およびdcommitし、すべてのgit-clone / pull / merge/pushを回避することをお勧めします。 gitリポジトリとブランチの間の操作。これらはgitsvncloneを介して取得され、変更セットをリモートSVNリポジトリにプッシュバックするためにも使用されます。
  • gitブランチとユーザーの間でコードを交換するための推奨される方法は、gitformat-patchとgitam、または単にgitsvndcommitをSVNリポジトリに送信することです。
  • gitsvndcommitは内部でgitsvnrebaseを使用するため、git svn dcommitの前にgitがプッシュするgitブランチでは、リモートリポジトリの既存の参照を強制的に上書きする必要があります。これは一般的に悪い習慣と考えられています。詳細については、git-pushのドキュメントを参照してください。
  • gitsvndcommitを実行する予定のブランチでgitmergeまたはgitpullを実行することはお勧めしません。SVNは合理的または有用な方法でマージを表していないため、SVNを使用しているユーザーは私たちが行ったマージを見ることができません。さらに、SVNブランチのミラーであるgitブランチからgitmergeまたはgitpullを実行すると、gitsvndcommitが間違ったブランチにコミットする可能性があります。
  • git cloneは、refs / remotes /階層、git-svnメタデータ、またはconfigの下にあるブランチのクローンを作成しません。したがって、git-svnを使用して作成および管理されるリポジトリは 、クローン作成を行う場合は、クローン作成にrsyncを使用する必要があります。
  • すでにコミットした変更に対して、gitcommitの--amendオプションを使用しないでください。他のユーザーのためにすでにリモートリポジトリにプッシュしたコミットを修正することは悪い習慣と考えられており、SVNを使用したdcommitはそれに類似しています。これについての詳細は、「単一コミットの変更」および「 履歴の書き換えに関する問題」を参照してください。
于 2009-12-10T11:55:03.370 に答える
3

私が以前行っていたのは、最初のgit svnクローンを作成し、次にgitを使用して開発者間で.gitを共有したため、まったく同じ参照がありました。

線形ツリーにとどまっている限り（つまり、マージではなくリベース）、gitユーザー間で「特定のgit機能」を使用できたため、正しく機能しているように見えました。

于 2009-12-10T11:44:28.137 に答える
2

Subversionリポジトリと同期したGitリポジトリの共有の問題を解決するツールがあります。

SubGitは、Git-SVN双方向サーバーサイドミラーです。

SubGitをSubversionリポジトリにインストールして、GitリポジトリをSVNと自動的に同期させることができます。

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGitはpre-commitフックとpost-commitフックをSubversionリポジトリにインストールし、pre-receiveフックとpost-receiveフックをGitリポジトリにインストールします。その結果、SVN側とGit側からの着信変更を即座に変換します。SubGitのインストール後、開発者は任意のGitクライアントを使用してGitリポジトリのクローンを作成して操作できます。

SubGitはgit-svnに依存せず、私たちのチームが開発した独自の翻訳エンジンを使用します。これについての詳細は、SubGitとgit-svnの比較で見つけることができます。SubGitに関する一般的なドキュメントは、こちらから入手できます。

SubGitのバージョン1.0には、Subversionリポジトリへのローカルアクセスが必要です。つまり、SVNリポジトリとGitリポジトリは同じホスト上に存在する必要があります。ただし、バージョン2.0では、Gitプロキシモードを導入します。SubversionリポジトリとGitリポジトリはどこにでも配置でき、GitリポジトリのみにSubGitがインストールされています。つまり、Subversionリポジトリは変更されません。

SubGitは商用製品です。オープンソースの学術プロジェクト、および最大10人のコミッターがいるプロジェクトは無料です。

免責事項：私はSubGit開発者の1人です。

于 2012-10-11T14:57:47.440 に答える
2

「分散」の問題に踏み込むとすぐに、開発者間で複製された1つの裸のgitリポジトリを使用したほうがよいでしょう。
パブリックSVNリポジトリへのエクスポート/インポートフェーズに関しては、他のユーザーが使用できるように、スクリプト
git2svnおよびsvn2gitが魔法のカプセル化に役立ちます。

GitおよびSVNリポジトリで作業する際のその他の考慮事項は、「ワークフローとgit、2つのsvnプロジェクトおよび1つの「ワークコピー」のヘルプ」という質問にあります。

于 2009-12-10T11:49:34.473 に答える
2

マスターブランチでプッシュ/プルを実行できるように、Subversionリポジトリと同期するために別のブランチを保持することを提案するこのブログ投稿を見つけました。

于 2010-06-11T18:53:55.433 に答える
1

git-svnで私が感じる問題の1つは、コミットコメントにgit-svn-idが格納されていることです。これはそのコミットを書き換えるため、SHA1に変更されるため、他のユーザーが共有する場所にプッシュすることはできません。

私は実際にはbzr-svnを好みます。代わりに、SVNリビジョンプロパティ機能を使用してリモートSVNリビジョンにbzr revidを保存します。これは、ローカルリビジョンの書き換えがないことを意味します。また、同じSVNブランチの2つの独立したプルにより、同一で相互運用可能なbzrブランチが生成されるという望ましい特性もあります。

于 2010-10-18T15:36:41.760 に答える