gitマージをロールバックしやすいようにするにはどうすればよいですか？

Question

gitでマージを元に戻すのが簡単ではないという話がたくさんあります。短いバージョン：マージコミットを元に戻すと、gitはそれらの変更を今後もマージしないように指示します。

この問題を回避するためにマージを行うときにできることはありますか？マージを元に戻すことは、ソフトウェア開発者の通常のコースだけで本当に便利な場面がたくさんあります。さらに重要なことは、変更をロールバックする必要があるリリースブランチの状態を制御することです。

編集

私はthis article溶液を見てきましたし、本当に問題の説明の多くの解決策、考えていません。それは、常に

は、あなたがそれらに依存するコードに持ち帰るしたい場合（これは数時間、日、週、または月可能性があり、すべてのあなたの元に戻す - マージを覚え--no-FFを使用

1. が必要です将来的に...）

私はここで

欲しいもの、それはSubversionの中でどのように動作するかです。ステージングサーバーで実行しているものと機能を試しているものの、「リリース候補」というブランチがあるとしましょう。フィーチャーAブランチをマージするとしましょう。 Subversionでは、すべて1つのチェンジセットであり、すべてのファイルのすべての履歴がマージされます。私たちはそれが好きではないと言いましょう。その単一のチェンジセットを元に戻すだけで、他のことについて考える必要はありません。私たちは、ある時点で私たちがそれをマージして取り出したことを覚えていなくても、将来、いつでもフィーチャーブランチAをマージすることができます。

できるだけそのフローに近づけたいと思っています。私は、物事をどうにかしてより多くのステップを踏み出させても、「将来的に物事を覚える必要はない」ために最適化したいと思います。 （これは...不可能かもしれません）

Answer 1

UPDATE：

それが簡単にブランチあたりの機能で動作するようになりワークフローはここにある：http://dymitruk.com/blog/2012/02/05/branch-per-feature/

---

の（SVN部分質問は最後に回答されました）

はい、ここでは結合解除された機能を再導入します。 （すでにマージ「を元に戻した」と仮定し）、次の歴史を考えてみましょう：あなたは、その機能の結合を解除するとき

x---x----x--x---x--M--U--L 
    \   /
     x--x--x--x-F 

FはMがマージされ、機能ブランチで、Uは、Lは、最新のコミットされ、反対です。ここで

あなたの選択肢は次のとおりです。

1. 差し戻しU（プッシュする必要がない--force）：

   x---x----x--x---x--M--U--L--^U 
       \   /
       x--x--x--x-F 
   

2. がLにFをリベース（そして--ff-only F'をマージ）（プッシュする必要がありません--force ）：

   x---x----x--x---x--M--U--L 
       \   /  \ 
        x--x--x--x-x   x'--x'--x'--x'--F' 
   

3. L上にFをリベースしない（そして--no-ff F'をマージ - あなたの新しい分岐点を維持する）（プッシュする必要なし--force）：

   x---x----x--x---x--M--U--L-------------------M2 
       \   /  \    /
        x--x--x--x-x   x'--x'--x'--x'--F' 
   

4. rebase -i head^^とリストからUをなくす（--forceがプッシュする必要がある） ：マージおよび結合解除を取り除くために

   x---x----x--x---x--M--L 
       \   /
        x--x--x--x-F 
   

5. rebase --onto M^1 L^ L。今度はFを後で修復することができます。

       L' 
          /
   x---x----x--x---x--M--U--L 
       \   /
        x--x--x--x-F 
   

初期マージに--squash修飾子を使用して、すべての機能がコミットスカッシュします。私はあなたの想像力が歴史の中でどのように見えるかについての作業をさせます。私はこれを行うことをお勧めしない理由があります。機能がどのように機能しているか、どのようなステップを取ったかを知ることには価値があります。その後のマージは、Gitが特定のファイルのように見える理由を調べることができるので簡単になります。コミットをまとめるとその情報が失われます。

あなたの履歴を活用する能力に影響する場合としない場合があります。

私がお勧めするのは、常にマスターで空白のマージで解放されたものをマークすることです。これは、--no-ffオプションとのマージを介して行われます。あなたはマスターでは決して作業しませんし、そこで行われる唯一のコミットはそれらのマージです - コード変更のコミットはありません。 QAブランチでは、リリースしたポイントを示すコミットにタグを付けます。したがって、git merge --no-ff rc-12.2を実行すると、コミットコメント「merged rc-12.2」が自動生成されます。

git-flowをチェックしてください。

希望の詳細を提供します。