私のマスターブランチでは、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.

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

で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で異なる作業ツリーのファイルを更新しますが、インデックスと作業ツリーで異なるファイル（つまり、追加されていない変更があるファイル）は保持します。

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

git reset --hard origin/master

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

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

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

git revert -m 1 commit_hash

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

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

git reset --merge ORIG_HEAD

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

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

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

git merge --abort

からman git merge：

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

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

git reset --hard HEAD^

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

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

最近、私はこれ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、このブランチにマージ前の追跡を強制し、持ち越します。

最新の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は毎日の仕事ではるかにパワフルで便利だと思うので、それをいつも使っています。

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

これをしています...

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

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

具体的には、

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

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

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

git reset --hard remotes/origin/HEAD

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

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

$ git checkout -f

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

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

git reset --hard @{u}

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

ヘッドを変更する必要があります。もちろん、ヘッドを変更する必要はありませんが、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ます。

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

最初に git reset --merge ORIG_HEAD

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

git push origin HEAD --force

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

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

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

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

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

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

頑張ってください！

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

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

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

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

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

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

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

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

1. キックオフgitk（コマンドラインから、またはファイルブラウザがある場合は右クリック）
2. そこでマージコミットを簡単に見つけることができます-2つの親を持つ上からの最初のノード
3. 最初/左の親へのリンクをたどります（マージ前の現在のブランチにある親、通常は赤）
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

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

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

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

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

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

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. git stash

2. git branch -d the_local_branch

3. git checkout -t <name of remote>

4. git stash apply

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

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

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

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

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

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

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

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