2011-01-19 13 views
9

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

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

編集

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

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

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

    私はここで

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

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

  • +0

    git reset -hard ORIG_HEADを使用してコミットをロールバックできない理由はありますか? – urschrei

    +0

    私の答えはより多くの情報を必要としますか? –

    +0

    urschrei:サーバー上のブランチでこれを実行した場合、結果をプッシュするには '--force'を使用する必要があります。 –

    答えて

    11

    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をチェックしてください。

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

    +1

    これは私の選択肢の素晴らしい概観ですが、私の質問は、物事をより簡単に進めるために、元のマージ時にできることがあれば私の質問でした。私はちょうど "私が欲しいもの"のセクションで質問を更新しました。 –

    +1

    あなたの答え:それらは4つの異なるオプションです、そうですか?番号を付けたいですか?また、すべてのブランチがリモートで公開されている場合、それらのうちどれに '--force'が必要ですか?あなたがそれらのように印をつけてくれればいいですか。 –

    +0

    私が心配する唯一のことは、あなたがメインラインで仕事をしていない場合です。これにより、早送りマージが行われます。これは、マージポイントを保持できません。その場合、マージを行うときに--no-ffを指定して、2つの親との空のコミットを確実にします。これにより分岐点が保持されます。あなたが何か他のものが必要な場合は教えてください。 –

    関連する問題