3

私は、SVN をリビジョン管理として使用する大規模なチームに所属しています。

私は、このサブグループのコードの統合テストに git を使用しようとする大きなチームのサブグループに属しています。

以下は、私たちが日々の仕事のためにやりたいことです。

  1. A、B、C (小グループの人々) がコーディング作業を行います。
  2. A,B,C 作業を git branch にチェックインしintegration-testます。
  3. SVN trunkからへの最新の変更をリベースしますintegration-test
  4. イメージをビルドし、統合テストを行います。
  5. テストパス、A、B、C のコードを 'SVN' にチェックイン
  6. ステップ 1 に進む

問題はintegration-test、ステップ 2 で変更が git ブランチにコミットされSVN、ステップ 5 で変更がコミットされたためです。したがって、次のラウンドのステップ 3 で、マージはすべての変更に対して競合します。

では、このシナリオに適した方法はありますか?

4

1 に答える 1

5

あなたが抱える問題は、git svn rebase実際にgitリポジトリのコミット履歴を書き換えることです。これにより、そのリポジトリからプルする人との競合が発生します。最善の解決策は、誰もがgit svn自分でsvnリポジトリにアクセスすることです。

ブランチを共有できるようにリモートリポジトリを設定する場合は、リモートgitブランチがsvnにリベースされている場合、新しいリビジョン履歴をローカルgitリポジトリに強制的に適用する必要があることに注意する必要があります。

他のユーザーは、を使用してローカルリポジトリをリモートと一致させることができgit pull --forceます。警告されますが、変更ポイント以降に行われたコミットは無効になるためです。たとえば、次のコミット構造があるとします。

       D----Eトピック
      /
A ---- B ---- C----Fマスター

次に、を使用git pull --forceしてローカルリポジトリを更新します。これにより、で始まるコミットのsha1が変更されBます。新しい構造は次のようになります。

       D----Eトピック

A ---- G ----H----マスター

どのようにコミットDしE、今不思議な土地に浮かんでいるかに注意してください。これは、分岐点が以前と一致しなくなったためBですが、現在はGです。

この問題を回避するには、ローカル分岐点が、を実行しても変更されないコミットから発生していることを確認する必要がありますgit svn rebase。git rebaseリモートを強制的にプルした後、ローカルブランチを更新リモートブランチに移すことができます。

コミットポイントからブランチを作成するのを間違えたとしましょう。その結果、上記の不思議の国が浮かんでしまいます。それでは、を開始する前にgitワンダーワンドを振る必要がありgit pull --forceます。そのようです：

おっと。Bで上書きされますpull。

       D----Eトピック
      /
A ---- B ---- C----Fマスター

それでは、git rebase A topic変更されないコミットで変更を加える必要があります。

  D'---E'トピック
 /
A ---- B ---- C----Fマスター

次に、変更が加えgit rebase G topicられると、変更を元の場所に戻すことができます。

       D'---E'トピック
      /
A ---- G ----H----マスター

うまくいけば、これがsvnリポジトリと一緒に中央アクセスgitリポジトリを実行しようとする苦痛を説明します。

于 2012-05-09T05:56:55.797 に答える