まだプッシュされていないGitマージを元に戻します


3944

私のマスターブランチでは、git merge some-other-branchローカルで行いましたが、変更をオリジンマスターにプッシュしませんでした。マージするつもりはなかったので、元に戻したい。git statusマージ後を実行すると、次のメッセージが表示されました。

# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.

私が見つけたいくつかの指示に基づいて、私は走ってみました

git revert HEAD -m 1

しかし、今私はこのメッセージを受け取りますgit status

# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.

私は自分のブランチが何回もコミットされることを望まない。どうすればその時点に戻ることができますか?


3
履歴を保存する必要がある場合、つまり、誰かがあなたからプルした、またはどこかにプッシュした変更がある場合は、以下のYuri Ushakovのソリューションを使用してください!
Sedrik、2011年

6
現在の優勝回答の選択を解除してください。投票を集めていますが、安全ではありません(多くの人が指摘したとおり)。私には「MBO」-sが最もよく見えますが、ポイントははるかに少ないです。
歌手2013年



3
これは、Githubから直接提供された優れたリソースです
。Git

回答:


4460

git reflogある従来のマージがコミットチェック(git reflogより良いオプションになりますgit log)。その後、次のコマンドを使用してリセットできます。

git reset --hard commit_sha

別の方法もあります:

git reset --hard HEAD~1

1つのコミットを取り戻します。

変更された、コミットされていない、またはスタッシュされていないファイルは、変更されていない状態にリセットされることに注意してください。それらを保持するには、変更を隠しておくか、--merge以下のオプションを参照してください。


@Velmontが彼の答えで以下に示唆したように、この直接的なケースでは以下を使用します:

git reset --hard ORIG_HEAD

変更が保存されるため、より良い結果が得られる可能性があります。ORIG_HEADマージが発生する直前にコミットを指すので、自分でそれを探す必要はありません。


もう1つのヒントは、ファイルを不必要にリセットしないため、--merge代わりにスイッチを使用すること--hardです。

git reset --merge ORIG_HEAD

- マージ

インデックスをリセットし、<commit>とHEADで異なる作業ツリーのファイルを更新しますが、インデックスと作業ツリーで異なるファイル(つまり、追加されていない変更があるファイル)は保持します。


129
これは(常に?)機能するとは思いません-「マージの1つ前」は、他のブランチからマージされた最新のコミットになります-現在のブランチでの最新のコミットではありません。正しい?(これはgit log、デフォルトで表示することを選択した結果の可能性があります-多分これの出力が異なるgit loggit reflog、これに使用できます)
John Bachir

6
スカッシュマージするかどうかにもよると思います。
Marcin Gil、

29
@JohnBachirは正しいです。ではgit log、出力、あなたは、2つの親のコミットを見てみたいです。1つはブランチの最新のコミット、もう1つはマージしたブランチの最新のコミットです。git reset --hardマージしたブランチの親コミットにしたい。
ジャスティン

7
@JohnBachir:「マージ」が実際に早送りでない限り、ログの先頭にある新しいコミットが発生し、このコミットには2つの親(タコを行う場合は2つ以上)があります。マージ)。この1つのマージコミットを削除すると、マージから受け取った古いコミットもすべて消えます。ただし、安全のために、リセット後にgitは新しいヘッドの場所を通知します:「HEAD is now at 88a04de <commit message>」。私はいつもそれを見て、自分が思ったとおりの結果になったことを確認します。私のプロジェクトでは、標準的なブランチ命名スキームを使用して、物事を覚えやすくしています。
Mark E. Haase、

44
私が便利だと思ったのは、「git reflog」を見て、マスターで行った最後のコミットを探すことでした。次にやるgit reset --hard <commit_sha>
マックス・ウィリアムズ

1456

あなたのローカルマスターがオリジン/マスターよりも進んでいないと仮定すると、あなたはできるはずです

git reset --hard origin/master

その場合、ローカルmasterブランチはと同じに見えるはずですorigin/master


71
@Carterそれは実際には最良の答えではありません。いくつかのコミットによって、オリジン/マスターがマージの直前にローカルマスターよりも進んでいる可能性があります。その場合、望ましい結果が得られない可能性があります
Dhruva Sagar

15
@ dhruva-sagarはい、しかしgitがあなたが遅れていると言わない限り、そしてあなたがフェッチしない限り、あなたは大丈夫です。
ケルビン

3
ありがとう!これは、リモートリポジトリがある場合(かつその場合のみ)に最適です。
tomc 2013年

2
いいえ、それはこの質問に最適なものではありません。「仮定」節を参照してください。MBOの答えは、実際にはこのケースをカバーしており、マージが唯一のローカルコミットではないケースをカバーしています。
歌手2013年

2
繰り返しになりますが、この警告は答え自体に含まれるはずです。常にgit履歴の書き換えを避けてください!
cregox 2013

1175

Gitブックの第4章Linus Torvaldsによる元の投稿を参照してください。

すでにプッシュされたマージを元に戻すに

git revert -m 1 commit_hash

Linusが言ったように、ブランチを再度コミットする場合は、必ず元に戻してください。


10
@perfectionistは同意しました:)一種の希望この回答を別の質問に移行する方法があった
mikermcneil

revertの詳細については、次のリンクを参照してください
assaqqaf 2014年

1
この復帰が機能したことを確信するには、git diff hash1 hash2を実行します。ここで、hash1はコミットされた復帰で、hash2は状態を戻そうとしていた古いコミットです。出力なし==成功!私はこれを複数回行うことにより、複数のコミットをロールバックすることができました。最初に、最新のマージを元に戻し、逆方向に作業しました。git diffを実行すると、目的の状態になったことがわかりました。
Robert Sinton 2014年

6
これは実際には元の投稿者の質問を解決しないことに注意してください。オリジナルポスターは、すでに使用しますgit revert -m 1 <commit>。問題は、それを行っても、彼が行った(まだプッシュしていない)偶発的なマージが消去されないことです。ハードリセットに関するその他の回答は、元の投稿者の問題に適しています。

これはGithubからのすばらしいリソースです:Gitで(ほとんど)何でも元に戻す方法
jasonleonhard

986

最も単純なコマンドが欠けていたのは奇妙です。ほとんどの答えは機能しますが、先ほど行ったマージを元に戻します。これは簡単で安全な方法です。

git reset --merge ORIG_HEAD

ref ORIG_HEADは、マージ前の元のコミットを指します。

(この--mergeオプションはマージとは何の関係もありません。それはと同じですがgit reset --hard ORIG_HEAD、コミットされていない変更に触れないので安全です。)


17
作業ツリーを汚してしまった場合は、git reset --merge ORIG_HEADそれらの変更を保存します。
2013

1
これが唯一の正しい答えです(これが最良の答えだとは言っていません-違いに注意してください)。マスターで、t1、t3、およびt5で3つのコミットを実行したとしましょう。たとえば、branch1で、t2、t4、t6に3つのコメントを付けたとします(t1、t2、t3、t4、t5、t6が時系列であると仮定します)。と同様のコマンドgit reset --hard HEAD~5は、HEADのみをリセットします(masterとbranch1の両方のコミットが削除される場合があります)。--mergeオプションのみがを削除しmergeます。
Manu Manjunath、2016

@Manuこの--mergeオプションは実際にはマージを削除しません--hard。使用しても問題はありません。ここで手がかりとなるのはORIG_HEADの参照です。その時点で立っている場所にマージする前に設定されます。:)
odinho-Velmont '25年

@yingted「作業ツリーを汚してしまった場合、git reset --merge ORIG_HEADはそれらの変更を保持します」とはどういう意味ですか。マージ後にファイルを変更するつもりでしたか?とにかく、私はマージを行ってから、いくつかの競合を解決しました。しかし、私はマージをリセットしたかったので、この回答で指示されたとおりにしました。すべてが問題なく、マージ後に行った変更が保存されていません。私のローカルリポジトリは、私がマージを行う前の位置とちょうど似ています。
サミサチャトゥランガ2016年

このgit reset --hard ORIG_HEADコマンドは私にとっては完璧に機能しましたgit merge。元に戻そうとしたローカルの後で、リポジトリに他の変更を加えなかったという事実が助けになった可能性があります。このコマンドは、リポジトリの状態をマージ前の状態にリセットするだけです。素晴らしいヒントをありがとう!
bluebinary 2017年

391

新しいGitバージョンでは、まだマージをコミットしておらず、マージの競合が発生している場合は、次のようにするだけです。

git merge --abort

からman git merge

[これ]は、マージによって競合が発生した後にのみ実行できます。git merge --abortマージプロセスを中止し、マージ前の状態を再構築しようとします。


8
彼のマージ(タイトルを参照)コミットが、押されていない、彼はすでに合併した彼は、マージの真ん中にまだあるときにのみ、あなたのコマンドは動作します
JBoy

135

前のコミットにリセットする必要があります。これはうまくいくはずです:

git reset --hard HEAD^

またはHEAD^^、そのコミットを元に戻すこともできます。実行する必要のあるステップ数がわからない場合は、いつでも完全なSHA参照を指定できます。

問題があり、masterブランチにローカルの変更がなかった場合は、にリセットできますorigin/master


5
最良の答えのIMHOは、OP自身のもの(Qでそうであるように思われる、元に戻すのに1ステップだけを想定)と、randomguy3のショートカットのもの(「マスターブランチにローカルの変更がない場合に機能する」)を組み込んでいます。 ")
歌手2013年

4
コメンター、@ Ingerと@Konstantin、なぜですか?私の答えが作成された後、あなたはここに来ました、そしてそれはより正確です。HEADを1つ上に上げるだけでは間違っていることがよくあります。実際にどれだけ上に行く必要があるかを数える必要があります。Gitはすでに設定さORIG_HEADれていますが、使用しないのはなぜですか?
odinho-Velmont 2014年

ローカルの変更もリセットしますか?#更新してください。
CoDe 2016

これは私にとっては完璧に機能し、そのように頭をリセットすることは、ここでの回答の半分よりもはるかに理にかなっています。
VardaElentári16年

HEAD ^はHEADより前のコミットに等しいですか?そして^^は2つのコミット前ですか?これは早送りマージでは機能しないと思いますか?
マーカスレオン

87

最近、私はこれgit reflogを支援するために使用しています。これは主に、JUSTマージが発生し、マシン上にある場合にのみ機能します。

git reflog 次のようなものを返すかもしれません:

fbb0c0f HEAD@{0}: commit (merge): Merge branch 'master' into my-branch
43b6032 HEAD@{1}: checkout: moving from master to my-branch
e3753a7 HEAD@{2}: rebase finished: returning to refs/heads/master
e3753a7 HEAD@{3}: pull --rebase: checkout e3753a71d92b032034dcb299d2df2edc09b5830e
b41ea52 HEAD@{4}: reset: moving to HEAD^
8400a0f HEAD@{5}: rebase: aborting

最初の行は、マージが発生したことを示しています。2行目はマージ前の時間です。私は単にgit reset --hard 43b6032、このブランチにマージ前の追跡を強制し、持ち越します。


すばらしい回答、ありがとうございます!マージを元に戻す必要がありましたが、他の回答reflogはSHAを取得してそれを機能させるために使用して、さらに混乱させgit resetました。
-Lankymart

51

最新のGitでは、次のことができます。

git merge --abort

古い構文:

git reset --merge

古い学校:

git reset --hard

しかし、実際に、それは注目に値するであるgit merge --abortだけに相当しgit reset --merge、与えられたMERGE_HEAD存在です。これは、マージコマンドのGitヘルプで読むことができます。

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

何がある場合に失敗し、マージした後、MERGE_HEAD失敗したマージはして元に戻すことはできませんgit reset --mergeが、必ずしもと、git merge --abort彼らは同じもののために古いものと新しい構文ではないだけですので

個人的にgit reset --mergeは毎日の仕事ではるかにパワフルで便利だと思うので、それをいつも使っています。


私にとってはうまくいきました。他のすべての投稿では、これは非常に複雑であると述べていますが、これは期待どおりの結果をもたらしました。競合があったためにしか機能しなかったと思います。競合は元の質問に正確に答えるものではありません。
ジェレミー

この回答はOPの状況に焦点を当てておらず、重要なコンテキストを除外しています。
Ben Wheeler

37

さて、ここの他の人が私に与えた答えは近いものでしたが、うまくいきませんでした。これが私がしたことです。

これをしています...

git reset --hard HEAD^
git status

...次のステータスを取得してください。

# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.

その後、同じgit resetコマンドをさらに数回入力する必要がありました。そのたびに、以下のようにメッセージが1つずつ変化しました。

> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 1 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.

この時点で、ステータスメッセージが変更されたgit pullことがわかりました。

> git pull
Updating 2df6af4..12bbd2f
Fast forward
 app/views/truncated |    9 ++++++---
 app/views/truncated |   13 +++++++++++++
 app/views/truncated |    2 +-
 3 files changed, 20 insertions(+), 4 deletions(-)
> git status
# On branch master

要するに、私のコマンドは次のとおりです。

git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git pull

19
または、あなたが使用したかもしれませんHEAD^^^^
Hasen

17
多分にリセットorigin/master;)
HASEN

23

git reflog以前のチェックアウトを見つけるために使用できます。時々それはあなたが戻りたい良い状態です。

具体的には、

$ git reflog
$ git reset --hard HEAD@{0}

1
ありがとうございました!あなたは私の仕事の半日を節約しました。しかし、どのコマンドでもreflogモードを終了できませんでした。
Katarzyna 2015

1
@Katarzynaは "q"キーを使用してreflogを終了します
Amjed Baig

21

マージの最中であれば、いつでも中止できます git merge --abort


2
仲間に感謝し、私はその恐ろしいことを正解しようとしていました。幸運なことに私は下にスクロールしました。マージヘッドを削除したいだけです
Nyuu

15

この問題は、コミットIDの検索を含まない単一のコマンドで解決できました。

git reset --hard remotes/origin/HEAD

受け入れられた答えは私にとってはうまくいきませんでしたが、このコマンドは私が探していた結果を達成しました。


丁度!ブランチのHEADへの変更をリセットします!一つ一つやっていない
カルロスジナート2018

うまくいきませんでした。実際には、1か月か2か月後に地元の支店を送り返すことになりました。ありがたいことに、これはすべてローカルなので、いつでもブランチを破棄して再度フェッチできます。他の人がこれを試した場合に備えて、それを指摘したかっただけです。
Matt Pengelly

@MattPengellyこのメソッドはほとんど文書化されておらず、マージを行う前にブランチがリモートブランチと同期している場合に通常は機能します。ブランチがリモートブランチと同期してから数ヶ月になりますか?
Ralph Ritoch

@MattPengellyは、HEADが指しているブランチにも依存します。私は私のプロジェクトの1つでgitflowを使用しています。開発ブランチにいても、remotes / origin / HEADはorigin / masterを指しているため、マージを元に戻す必要がある場合は、おそらくremotesにリセットする必要があります。 / origin / develop
Ralph Ritoch

14

まだコミットしていない場合は、

$ git checkout -f

マージ(および実行したすべて)を取り消します。


これを試したところ、私のローカルブランチが先に行っているコミットの数が実際に増えました。
バークレー2015年

14

元の一致に戻すことも目的としてこの質問に行きました(つまり、元の前のコミットはありません)。さらに調査したところ、resetそのためのコマンドがあることがわかりました。

git reset --hard @{u}

注:@{u}はの省略形ですorigin/master。(そしてもちろん、これを機能させるにはリモートリポジトリが必要です。)


14

ヘッドを変更する必要があります。もちろん、ヘッドを変更する必要はありませんが、git HEAD ...

答える前に、背景を追加して、これが何であるかを説明しましょうHEAD

First of all what is HEAD?

HEAD現在のブランチの現在のコミット(最新)への参照です。
常に1つしか存在できませんHEAD。(除くgit worktree

の内容HEADは内部に格納され.git/HEAD、現在のコミットの40バイトのSHA-1が含まれています。


detached HEAD

あなたが最新のコミットをしていない場合-これHEADは、履歴内の以前のコミットを指していることを意味しdetached HEADます。

ここに画像の説明を入力してください

コマンドラインでHEADは、は現在のブランチの先端を指していないため、ブランチ名ではなく、SHA-1のようになります。

ここに画像の説明を入力してください

ここに画像の説明を入力してください

切り離されたヘッドから回復する方法に関するいくつかのオプション:


git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

これにより、目的のコミットを指す新しいブランチがチェックアウトされます。
このコマンドは、特定のコミットにチェックアウトします。
この時点で、ブランチを作成して、この時点から作業を開始できます。

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

いつでも使用できreflogます。
git reflog更新された変更が表示さHEADれ、目的のreflogエントリをチェックアウトすると、HEADこのコミットに戻ります。

HEADが変更されるたびに、新しいエントリが reflog

git reflog
git checkout HEAD@{...}

これにより、目的のコミットに戻ります

ここに画像の説明を入力してください


git reset --hard <commit_id>

HEADを目的のコミットに「移動」します。

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.
  • 注:(Git 2.7以降
    も使用できgit rebase --no-autostashます。

git revert <sha-1>

指定されたコミットまたはコミット範囲を「元に戻す」。
リセットコマンドは、指定されたコミットで行われた変更を「取り消し」ます。
元に戻すコミットを含む新しいコミットはコミットされますが、元のコミットも履歴に残ります。

# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

このスキーマは、どのコマンドが何を実行するかを示しています。
ご覧のとおり、をreset && checkout変更しHEADます。

ここに画像の説明を入力してください


これは宝物です🐱‍👤🐱‍👤🐱‍👤
Jawand Singh

12

最も単純な答えは、odinho-Velmontによって与えられたものです

最初に git reset --merge ORIG_HEAD

変更がプッシュされた後にリセットしたい場合は、これを実行してください(これはgit resetマージの質問で最初に表示される投稿であるため)

git push origin HEAD --force

これは、プルした後にマージされた変更を再び取得しない方法でリセットされます。


10

追加のオプションを確認するために、私はほとんどここで説明されている分岐モデルに従っています:http : //nvie.com/posts/a-successful-git-branching-model/そして、そのため--no-ff(早送り)通常。

デプロイのために、リリースブランチの代わりにテストブランチをマスターと誤ってマージしたので、このページを読んだだけです(Webサイト、マスターはライブです)。テスト版ブランチには他に2つのブランチがマージされており、合計で約6回のコミットが行われます。

したがって、コミット全体を元に戻すには、必要なのは1つだけでgit reset --hard HEAD^、マージ全体が元に戻りました。マージは早送りされなかったので、マージはブロックであり、1つ前のステップは「ブランチはマージされません」です。


10

マージを元に戻す、または特定のコミットで再起動するには、2つのコマンドしか使用できません。

  1. git reset --hard commitHash (再起動するコミットを使用する必要があります。例:44a587491e32eafa1638aca7738)
  2. git push origin HEAD --force (新しいローカルマスターブランチをorigin / masterに送信する)

頑張ってください!


10

複数の方法で実行できます。

1)マージを中止

間違ったマージの間に(間違ったブランチで誤って行われた)間で、マージが次のように最新のブランチに戻るのを避けたい場合:

git merge --abort

2)リモートブランチにHEADをリセットする

リモート開発ブランチから作業している場合は、以下のようにリモートブランチの最後のコミットにHEADをリセットできます。

git reset --hard origin/develop

3)現在のブランチを削除し、リモートリポジトリから再度チェックアウトする

ローカルリポジトリの開発ブランチで作業していて、リモート/開発ブランチと同期していることを考慮して、次のように実行できます。

git checkout master 
##to delete one branch, you need to be on another branch, otherwise you will fall with the branch :) 

git branch -D develop
git checkout -b develop origin/develop

「1)マージの中止」で十分です。賛成票。
CodeToLife

1
注意してください!--abort gitのマージ「のみのマージ後に実行することができますが、競合をもたらしたマージ処理を中止し、前のマージ状態を再構築しようとします--abort gitのマージ。」
ペドロ・ガルシアメディナ

8

マージと対応するコミットがまだプッシュされていない場合は、いつでも別のブランチに切り替え、元のブランチを削除して再作成できます。

たとえば、私は開発ブランチを誤ってマスターにマージし、それを元に戻したかった。次の手順を使用します。

git checkout develop
git branch -D master
git branch -t master origin/master

出来上がり!マスターはオリジンと同じ段階にあり、誤ってマージされた状態は消去されます。


1
注:これにより、マージが取り消されるだけでなく、オリジンへの最後のプッシュ以降に行われたローカルコミットも取り消されます。
Martijn Heemels 2012年

4

コマンドラインソリューションが必要な場合は、MBOの答えをそのまま使用することをお勧めします。

あなたが初心者であれば、グラフィカルなアプローチが好きかもしれません:

  1. キックオフgitk(コマンドラインから、またはファイルブラウザがある場合は右クリック)
  2. そこでマージコミットを簡単に見つけることができます-2つの親を持つ上からの最初のノード
  3. 最初/左の親へのリンクをたどります(マージ前の現在のブランチにある親、通常は赤)
  4. 選択したコミットで、[ここにブランチをリセット]を右クリックして、ハードリセットを選択します

4

戦略:すべてが良かったところから新しいブランチを作成します。

根拠:マージを元に戻すのは困難です。解決策が多すぎます。マージをコミットしたかプッシュしたか、マージ後に新しいコミットがあったかどうかなど、多くの要因によって異なります。また、これらのソリューションをケースに適応させるには、gitを比較的深く理解する必要があります。盲目的にいくつかの指示に従うと、何もマージされない「空のマージ」になってしまう可能性があり、さらにマージしようとすると、Gitに「すでに最新」と通知されます。

解決:

にマージdevしたいとしましょうfeature-1

  1. マージを受け取りたいリビジョンを見つけます:

    git log --oneline feature-1
    a1b2c3d4 Merge branch 'dev' into 'feature-1' <-- the merge you want to undo
    e5f6g7h8 Fix NPE in the Zero Point Module <-- the one before the merge, you probably want this one
    
  2. 確認してください(時間をさかのぼってください):

    git checkout e5f6g7h8
    
  3. そこから新しいブランチを作成し、チェックアウトします。

    git checkout -b feature-1
    

これでマージを再開できます:

  1. マージ: git merge dev

  2. マージの競合を修正します。

  3. コミット: git commit

  4. 結果に満足したら、古いブランチを削除します。 git branch --delete feature-1


2

新しいブランチを作成してから、目的のコミットを選択してください。

上記の多くの回答で説明されているように、そのセーバーとシンプルなリセット


1
リストされているgitコマンドに完全に慣れていない場合は特に、この提案に同意します。これは「労力」が増えると遅くなる可能性がありますが、それがあまり上手くいかず、作業を失うことに不安がある場合は、努力する価値があります。
グレッグ

1

git rebase -i [hash] [branch_name] どこ[hash]まで巻き戻したいか、または1つ前に戻したいコミットの識別ハッシュがどこにあるかを確認してから、エディターで、不要になったコミットの行を削除できます。 。ファイルを保存します。出口。祈る。そしてそれは巻き戻されるべきです。を実行するgit reset --hard必要があるかもしれませんが、この時点では問題ないはずです。履歴に残したくない場合は、これを使用してスタックから特定のコミットをプルすることもできますが、リポジトリがおそらく望ましくない状態のままになる可能性があります。


1

マージをコミットした場合:

git reset HEAD~1
# Make sure what you are reverting is in fact the merge files
git add .
git reset --hard

1
  1. まず、すべてをコミットしたことを確認してください。

  2. 次に、リポジトリを以前の動作状態にリセットします。

    $ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36
    

    または使用--hardこれにより、コミットされていないローカルの変更がすべて削除されます!):

    $ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36 --hard
    

    誤ってマージされたコミットの前にあったハッシュを使用します。

  3. 次の方法で、以前の正しいバージョンの上に再コミットするコミットを確認します。

    $ git log 4c3e23f529b581c3cbe95350e84e66e3cb05704f
    
    commit 4c3e23f529b581c3cbe95350e84e66e3cb05704f
    
    ...
    
    commit 16b373a96b0a353f7454b141f7aa6f548c979d0a
    
    ...
    
  4. リポジトリの正しいバージョンの上に正しいコミットを適用するには:

    • チェリーピックを使用する(既存のコミットによって導入された変更)

          git cherry-pick ec59ab844cf504e462f011c8cc7e5667ebb2e9c7
      
    • または、次の方法でコミットの範囲を選択します。

      • マージする前に、まず正しい変更を確認します。

        git diff 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
        
      • マージする前に、まず正しい変更を確認します。

        git cherry-pick 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
        

        ここで、これはあなたがコミットした正しいコミットの範囲です(誤ってコミットされたマージを除く)。


1
  1. git stash

  2. git branch -d the_local_branch

  3. git checkout -t <name of remote>

  4. git stash apply

これは私のために働いた.. !!


0

マージの直後に元に戻す必要があり、マージの試行後に他に何も実行していないことに気付いた場合は、次のコマンドを発行できます git reset --hard HEAD@{1}

基本的に、マージshaHEAD@{0}、マージ後に他に何もコミットされていない場合を指しているためHEAD@{1}、マージ前の以前のポイントになります。


0

最も単純なチャンスの中で最も単純で、ここで述べたことよりもはるかに単純です。

ローカルブランチ(リモートではなくローカル)を削除して、もう一度プルします。これにより、マスターブランチの変更を元に戻すことができ、プッシュしたくない変更の影響を受けます。やり直してください。


0

この場合、ブランチをでリセットする必要がありますgit reset --hard <branch_name>。変更をリセットする前に保存したい場合は、必ず新しいブランチを作成し、git checkout <branch_name>

状態を特定のコミットにリセットできます git reset --hard <commit_id>ます。

変更がプッシュされている場合は、git revert <branch_name>代わりに使用できます。他のシナリオでもgit revertとgit checkoutを使用する方法を必ず確認してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.