Gitマージをロールバックする


225
develop branch
--> dashboard (working branch)

git merge --no-ff develop上流の変更をダッシュ​​ボードにマージするために使用します

git log:

commit 88113a64a21bf8a51409ee2a1321442fd08db705
Merge: 981bc20 888a557
Author: XXXX <>
Date:   Mon Jul 30 08:16:46 2012 -0500

    Merge branch 'develop' into dashboard

commit 888a5572428a372f15a52106b8d74ff910493f01
Author: root <root@magneto.giveforward.com>
Date:   Sun Jul 29 10:49:21 2012 -0500

    fixed end date edit display to have leading 0

commit 167ad941726c876349bfa445873bdcd475eb8cd8
Author: XXXX <>
Date:   Sun Jul 29 09:13:24 2012 -0500

マージには約50以上のコミットがあり、ダッシュボードがマージ前の状態に戻るようにマージを元に戻す方法を知りたいです。

これの2番目の部分は、とマージしない場合--no-ff、コミット ' マージブランチ'開発 'からダッシュボード 'を取得できません。どうすればマージをロールバックできますか?


3
Undo a Gitマージの重複の可能性はありますか?。

回答:


320

マージコミットを元に戻すことは、他の質問で徹底的にカバーされています。2番目に説明する早送りマージを実行するgit resetと、前の状態に戻すために使用できます。

git reset --hard <commit_before_merge>

あなたは見つけることができます<commit_before_merge>しgit reflog、git logあなたがMOXYを感じている(と何かを行っていない)場合、または:git reset --hard HEAD@{1}


6
迅速な返信に感謝.. git logを見ると、マージ前のコミットは50以上のコミットが返されます。マージがどこに/どこにあるのかわからない場合は、どうすればそれを見つけることができますか?あなたはcommit_before_mergeを見つけることについて言及しています..私はその部分を理解していないと思います
— cgmckeever

4
git reflogのように見えますが、最後のヘッドをうまく要約しているように見え、どこにリセットする必要があるかを知ることができます。git logは、リセットする場所を正確に特定するには細かすぎます。ありがとう
— cgmckeever

1
ええ、reflog'命の恩人です。HEAD@{1}HEADの2番目に最近の状態、またはより技術的には次のように説明します。 ref。」
— クリストファー

4
復帰をリモートにプッシュするのはどうですか?どのように機能するのかわかりません。
— アントンサヴェリエフ

2
これは絶望的です。マージ後にすべてのコミットを破棄します。
— aaa90210

151

ここから:

http://www.christianengvall.se/undo-pushed-merge-git/

git revert -m 1 <merge commit hash>

Git revertは、指定されたコミットをロールバックする新しいコミットを追加します。

-m 1を使用すると、これがマージであり、マスターブランチの親コミットにロールバックする必要があることがわかります。-m 2を使用して、developブランチを指定します。


30
ドキュメントが言うように、この後にブランチを再マージすることはできないことに注意してください。「マージコミットを元に戻すと、マージによってツリーの変更が取り込まれることは決してないことが宣言されます。その結果、後のマージでは導入されたツリーの変更のみが取り込まれます。以前に元に戻されたマージの祖先ではないコミットによって。これは必要な場合とそうでない場合があります。」
— DaliborKarlović15年

23
@DaliborKarlovićそのステートメントは少し厳しいです。後で間違いなくこれらの変更を元に戻すことができます。コツは、コミットを元に戻すことです。詳細はこちらのセクションの「元に戻すを元に戻す」
— Hilikus

3
残念ながら、here@ Hilikusコメント内のリンクは無効になっています。このサイトは、コンテンツがブック(git-scm.com/book/en/v2)に移動されたと主張していますが、その場合、そこに配置することは簡単ではありません。
— ジェシーチザム

@DaliborKarlovićこれは、@ Christopherからの上記の答えとのケースですか?
— James B

3
元に戻すマージコンテンツはここ
— SEK

28

マージコミットをリセットするだけgit reset --hard HEAD^です。

--no-ffを使用すると、間にコミットを行わなかった場合でも、gitは常にマージを作成します。--no-ffを指定しない場合、gitは単に早送りを実行します。つまり、ブランチのHEADはマージされたブランチのHEADに設定されます。これを解決するには、元に戻したいcommit-idを見つけますgit reset --hard $COMMITID。


1
マージ前のコミットがわからない場合の良い解決策。
— iglesiasedd 2017年

コミットIDがわからないため、私のために働きました。+ 1
— Anant Singh --- Alive to Die

不要なマージがすでにリモートにコミットされている場合は、git push -fを使用して、復帰後にリモートブランチを更新しました。
— zumek

16
git revert -m 1 88113a64a21bf8a51409ee2a1321442fd08db705

ただし、予期しない副作用が発生する可能性があります。git-scm.com/docs/git-revertの--mainline parent-numberオプションを参照してください

おそらく、野蛮だが効果的な方法は、そのコミットの左側の親をチェックアウトし、すべてのファイルのコピーを作成し、HEAD再度チェックアウトして、すべての内容を古いファイルに置き換えることです。次に、gitは何がロールバックされているかを通知し、独自の復帰コミットを作成します:)!


1
+1は、この回答がリセットのように履歴を台無しにしないためです(すでにリモートにプッシュしている場合は本当に重要です)。しかし、どのような予期しない副作用が予想されますか?
— pedromanoel 2015

3
これはあなたが言及した副作用ですか? Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.
— pedromanoel 2015

1
あなたgit resetは解決策であると言いますが、予期しない副作用が生じる可能性があることにも言及します。しかし、そのリンクから提示されgit revertていない、git reset:)
— マーク・

2
git resetには-mフラグがないことに注意してください。また、@ JorgeOrpinelはgit-resetではなくgit-revertドキュメントを参照することに注意してください。彼は言うgit revertgit reset
— Devin Gleason Lambert

メインラインを回避する方法は指定されましたが、コミット1234xyzはマージエラーではありません。
— アハル

0

ブランチをマージした場合、プルリクエストを使用してマージを元に戻し、そのプルリクエストをマージして元に戻します。

私が感じた最も簡単な方法は:

  1. (マージした)develop / masterから新しいブランチを取り出します
  2. git revert -m 1 xxxxxx(ブランチを使用してリバートがマージされた場合)またはを使用して、「リバート」をリバートします。git revert xxxxxxされた場合単純なリバートであった場合にリバートします。
  3. 新しいブランチには、再度マージしたい変更が含まれているはずです。
  4. 変更を加えるか、このブランチをマージして開発/マスターします
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.