9

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

この問題を軽減するためにマージを行うときにできることはありますか？ソフトウェア開発の通常の過程で、さらに重要なことに、変更をロールバックする必要があるときにリリースブランチの状態を制御する際に、マージを元に戻すことが本当に本当に役立つ状況はたくさんあります。

編集

私はこの記事で解決策を見てきましたが、実際には解決策とは考えていません。問題の説明の詳細です。必要です

  1. 常に--no-ffを使用してください
  2. それらに依存するコードを戻したい場合は、元に戻されたすべてのマージを覚えておいてください（これは、数時間、数日、数週間、または数か月先になる可能性があります…）

私が欲しいもの

Subversionでの動作は次のとおりです。「release-candidate」というブランチがあるとしましょう。これは、ステージングサーバーで実行し、機能を試す場所です。機能Aのブランチにマージするとします。Subversionでは、これはすべて1つのチェンジセットであり、すべてのファイルのすべての履歴がマージされます。気に入らないので取り出したいとしましょう。その単一のチェンジセットを元に戻すだけで、他のことを考える必要はありません。機能ブランチAは、ある時点でマージして取り出したことを覚えていなくても、将来いつでもマージできます。

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

4

1 に答える 1

11

アップデート：

branch-per-featureの操作を容易にするワークフローは次のとおりです：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. FをLにリベースします（次にマージし--ff-only F'ます）（--forceプッシュする必要はありません）：

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

  3. FをLにリベースします（次にマージし--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は特定のファイルがそのように見える理由の履歴を調べることができるため、その後のマージはより簡単になります。コミットを一緒に押しつぶすと、その情報が失われます。

rerere履歴を利用する能力に影響する場合と影響しない場合がある追加の欠点があります。

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

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

それがあなたにもっと詳細を提供することを願っています。

于 2011-01-19T22:07:49.950 に答える