1

最善の努力にもかかわらず、私たちは Git リポジトリのフィーチャー ブランチで非常に困難な状況に陥ってしまいました。最終結果はgit diff develop..feature-branch、完全に予期しない差分が表示されることです。

たとえば、develop で追加された 1 つのファイルは、差分では削除として表示されます。他の多くのファイルも同様の問題を示しており、欠落しているもの、追加されているもの、多くの予期しない変更が多数あります。含まれているはずの一部のファイルdevelopは、差分にも表示されません。プル リクエストを介してコードをレビューしたときに、Atlassian Stash の問題に最初に気付きました。保留中のマージは完全に正しくなく、マージ中の標準的な競合解決では解決できません。

この原因の解読を試みたところ、問題は開発者が既にオリジンにプッシュされたフィーチャー ブランチのコミットに対して数回のリセットを実行したことが原因であると考えられます。これは、プル リクエストのコード レビュー中に提案されたいくつかの変更を「元に戻す」ためのものでした。具体的には、これがイベントのタイムラインであると考えています。

  1. 開発から作成された機能ブランチ
  2. 機能ブランチで実行される作業
  3. Atlassian Stash で生成されたプル リクエスト (PR は問題ないように見えますが、いくつかのマイナーな編集が​​提案されています)
  4. 開発者はリセットを使用して一部の変更を元に戻し、それらを元にプッシュします
  5. 一方、開発ブランチと機能ブランチの間でマイナーな競合が見つかりました
  6. 開発者は、develop からの機能ブランチを更新して競合を調整し、オリジンにプッシュします
  7. プル リクエスト (diff) は、以前のものとは大幅に異なる予期しない diff を示します。コミットされると予想されるファイルが見つからない、またはその逆
  8. 「悪い」マージを元に戻して（リセットではなく元に戻して）、もう一度試してみます。ただし、PR/差分は、保留中のマージに対して同じ誤った変更を示しています
  9. その後、開発者が開発からの最初のマージの前にどこかでリセットを使用したことがわかりました。

そこで、質問が 3 つあります。

  1. 変更を正しく開発にマージできるように、修正された機能ブランチをどのように「回復」する必要がありますか? 私の考えは、リセット前に発生することが知られている機能ブランチのコミットから、新しい「良い」機能ブランチを作成することです。次に、必要なコミットを「悪い」機能ブランチから「良い」機能ブランチにチェリーピックして、再作成することができます。最後に、「良い」フィーチャー ブランチを開発にマージし、「悪い」フィーチャー ブランチを削除します。

  2. 「悪い」機能ブランチを開発にマージすると、ファイルの状態が正しくないことを除けば、他の「破損」が開発ブランチに漏れることになります。つまり、汚染された「悪い」機能ブランチは、開発ブランチとその下流の何かをさらに汚染しますか? もちろん、これを行う予定はありませんが、その影響を理解したいと思っています。

  3. 私が説明したようにリセットすると、私が見ている問題が発生しますか、それとも他の何かに関連している可能性がありますか?

4

1 に答える 1

1

開発者の「リセット」は、オリジンへの「強制プッシュ」を行わない限り、おそらくオリジンに影響を与えませんでした。私の経験では、このようなことが起こった場合、それは不適切なマージまたは競合解決プロセスが原因です (つまり、上記のステップ #6 の何かが原因であると思われます)。本能は正しいです。あなたの最善の策は、悪いマージの前に新しいブランチを作成し (例: "feature-branch2")、元のブランチを破棄して (マージや、既にオリジンにプッシュされたその他の変更を元に戻すのは難しいため)、マージを再試行することです。それは悪くなりました。

「元に戻す」が、悪いマージを元に戻すために本当にやりたいことかどうかはわかりません。私の理解では、「元に戻す」は単一のコミットからパッチを逆適用し、マージを逆に適用しようとすると、マージが 1 つのコミットで 2 つの差分であるため、粘着性があるように聞こえます (私は「元に戻す」の経験があまりないため、たぶんそれができるかもしれません、私にはわかりません）。この問題を解決する最も安全で信頼できる方法は、新しいブランチを作成し、マージが不適切なブランチの使用を停止することです。

于 2014-07-21T13:20:14.337 に答える