Git - 変更を正しく元に戻す方法は？

Question

私はちょうどgitに切り替えました（gitflow分岐モデルを使用しています）、変更を取り消す必要があるときにはいくつか問題があります。

残念ながら、回帰中に発見された問題やテストサイクルのかなり遅い時点で、機能がリリースに移行しないことがかなり頻繁に判断されます。フィーチャーブランチのマージコミットを簡単に元に戻すことができますが、悪い変更がマージされた後に機能ブランチがカットされると、その変更が含まれ、リリース前にリリースブランチまたはリリースブランチに戻すことができます。

例：

       |reverts f1 
develop-> X---o---o---Y---Z---R---P <- merge f2 to develop picks up f1 
      \  / \ /
     f1-> A---B---C f2-> D---E 

例から、F1が切断され、上の仕事を、と開発に戻ってマージ。 f2がカットされ、作業が開始されます。 f1はコミットRで展開から復帰します。f2は完了し、コミットPで展開するために再び結合されます。コミットPは問題がある場所です：f1はこのコミットを介して開発に戻ります。さて、復帰に間違っていることがありますか？復帰したコミットが開発に戻らないようにする方法はありますか？ 'revert -m1'を使用して元に戻ります。

マージコミットを元に戻すときに間違っていることはありますか？私たちがそれを作ることができる方法はありますか？f2が拾ったf1からのコミットは、マージバックには含まれません。すべてのフォワードフィーチャーブランチでそれらのコミットを手作業で元に戻す必要がありますか？代わりに、マスターからすべての機能ブランチを削除する必要があるので、元に戻す可能性のある機能の変更を取り込むことはできません。

何か提案は歓迎です、ありがとう！

Answer 1

ワークフローには何も問題はないと思いますが、開発ブランチだけでなくすべての子に適用されるので、コミットの復帰を考慮する必要があります。フィーチャーブランチf2にはf1の変更、つまりf2 = f2 + f1という例があり、f2をgitにマージすると、f1も元の状態に戻ってくれると思うので、

上記の例では、実行したいことを達成するために、f2ブランチにRをコミットすることができます。

       |reverts f1 
develop-> X---o---o---Y---Z----R----P <- merge f2 to develop picks up f1 
      \  / \  /
     f1-> A---B---C f2-> D--R'--E 
           **|reverts f1** 

これは、f2が長時間実行されていることを前提としています。そうでなければ、それを短い枝にしようと思っていれば、私は復帰Rを控え、f2とその姉妹を併合してからやり直すことになるでしょう。これは、かなりの機能が並行して処理されている場合に便利です。

         **|reverts f1** 
develop-> X---o---o---Y---Z-------P---R-- < 
      \  / \ /
     f1-> A---B---C f2-> D---E 

これが役立ちます。