まだプッシュされていないGitイメージを元に戻す
私のマスターブランチ内で、私はローカルにgit merge some-other-branchをしましたが、Originマスターに変更をプッシュしませんでした。マージするつもりはなかったので、元に戻したいと思います。マージ後に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を使用して、どのコミットがマージの1つ前のコミットかを確認します（git reflogはgit logよりも優れたオプションです）。それからあなたはそれをリセットすることができます：
git reset --hard commit_sha
他にも方法があります。
git reset --hard HEAD~1
1コミットします。
修正されコミットされていない/スタッシュされていないファイルは修正されていない状態にリセットされることに注意してください 。変更を隠すか、以下の--mergeオプションを見てください。
@Velmontが以下の彼の答えで示唆しているように、この直接的なケースでは以下を使用します。
git reset --hard ORIG_HEAD
変更が保存されるため、より良い結果が得られる可能性があります。 ORIG_HEADはマージが行われる直前にコミットを指すので、あなたは自分でそれを探す必要はありません。
不必要にファイルをリセットすることはないので、さらなるヒントは--mergeの代わりに--hardスイッチを使用することです。
git reset --merge ORIG_HEAD
- マージ
インデックスをリセットし、<commit>とHEADの間で異なる作業ツリー内のファイルを更新しますが、インデックスと作業ツリーの間で異なるファイル（つまり、追加されていない変更があるファイル）は保持します。
あなたのローカルマスターがOrigin/masterより進んでいないと仮定すると、あなたはできるはずです。
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参照を指定できます。
問題があり、あなたのマスターブランチにローカルな変更がない場合は、Origin/masterにリセットすることができます。
最近、私はこれを手助けするためにgit reflogを使っています。これはほとんどの場合、マージが発生し、それがあなたのマシン上にある場合にのみ有効です。
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 checkout -f
それはマージ（そしてあなたがしたことすべて）を元に戻します。
この質問に行き、Originと一致するように戻ろうとしています（すなわち、NOはOriginより先にコミットします）。さらに調べてみると、それにはresetコマンドがあることがわかりました。
git reset --hard @{u}
注：@{u}はOrigin/masterの省略形です。 （もちろん、これを機能させるにはそのリモートリポジトリが必要です。）
余分なオプションを見るために、私は主にここで説明されている分岐モデルに従っています： http://nvie.com/posts/a-successful-git-branching-model/ and asそのようなものは通常--no-ff（早送りなし）とマージされています。
リリースブランチの代わりにテストブランチを展開用のマスターに誤ってマージしたため、このページを読みました（ウェブサイト、マスターはライブです）。テストブランチには、他の2つのブランチがマージされており、合計で約6つのコミットがあります。
したがって、コミット全体を元に戻すには、1つのgit reset --hard HEAD^だけが必要で、マージ全体が元に戻りました。マージは早送りされなかったため、マージはブロックであり、1つ前のステップは「ブランチはマージされません」です。
マージを元に戻すため、または特定のコミットで再開するために使用できるコマンドは2つだけです。
git reset --hard commitHash（再起動したいコミットを使用する必要があります。例えば、44a587491e32eafa1638aca7738）git Push Origin HEAD --force（新しいローカルマスターブランチをOrigin/masterに送る）
頑張って先へ進んでください！
最も簡単な答えはodinho - Velmontの答えです。
最初にgit reset --merge ORIG_HEADを行います
変更がプッシュされた後にリセットしようとしている人のために、これをしてください。
git Push Origin HEAD --force
プル後にマージされた変更が元に戻らないように、これはリセットされます。
マージとそれに対応するコミットがまだプッシュされていない場合は、いつでも別のブランチに切り替えて元のブランチを削除してから再作成できます。
たとえば、誤って開発ブランチをmasterにマージし、それを元に戻したいと思いました。以下の手順で行います。
git checkout develop
git branch -D master
git branch -t master Origin/master
ほら！マスターはオリジンと同じ段階にあり、あなたのミスマージ状態は消去されます。
コミットIDを調べる必要のない単一のコマンドでこの問題を解決できました。
git reset --hard remotes/Origin/HEAD
受け入れられた答えは私のために働かなかったが、この命令は私が探していた結果を達成した。
コマンドラインソリューションが必要な場合は、MBOの回答に従うことをお勧めします。
あなたが初心者なら、グラフィカルなアプローチが好きかもしれません。
gitkを起動します（コマンドラインから、あるいはファイルブラウザで右クリックします）。- マージコミットを簡単に見つけることができます - 上から2番目の親を持つ最初のノード
- 最初の/左の親へのリンクをたどる（マージの前に現在のブランチにあるもの、通常は赤）
- 選択したコミットで、[ここにブランチをリセット]を右クリックし、そこでハードリセットを選択します。
戦略： すべてがうまくいったところから新しいブランチを作成する。
理論的根拠： /マージを元に戻すのは難しい。マージをコミットしたのかプッシュしたのか、マージ後に新しいコミットがあったのかなど、多くの要因によっては解決方法が多すぎます。また、これらのソリューションをあなたのケースに適応させるためには、gitについて比較的深い理解が必要です。盲目的に指示に従うと、何もマージされない「空のマージ」になってしまう可能性があります。さらにマージを試みると、Gitは「すでに最新です」と通知します。
解決策：
devをfeature-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それをチェックしてください（時間をさかのぼって）：
git checkout e5f6g7h8そこから新しいブランチを作成してチェックアウトします。
git checkout -b feature-1
これでマージを再開できます。
マージ：
git merge devマージの競合を修正してください。
コミット：
git commit結果に満足したら、古いブランチを削除します。
git branch --delete feature-1
HEADを変更する必要があります。もちろん、自分のものではなく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のようになります。
切り離されたHEADから回復する方法に関するいくつかのオプション：
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>
指定されたコミットまたはコミット範囲を「元に戻す」。
resetコマンドは、特定のコミットで行われたすべての変更を「元に戻します」。
元に戻すコミットを含む新しいコミットはコミットされますが、元のコミットも履歴に残ります。
# 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を変更します。
マージ中の場合はいつでも中止できます git merge --abort
私はあなたが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
まず、すべてをコミットしたことを確認してください。
その後、リポジトリを以前の作業状態にリセットします。
$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36または
--hard（ これはコミットされていないすべてのローカルの変更を削除します！ ）：$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36 --hard誤ってマージされたコミットの前にあったハッシュを使用してください。
次の方法で、以前の正しいバージョンの上にどのコミットを再コミットするのかを確認します。
$ git log 4c3e23f529b581c3cbe95350e84e66e3cb05704f commit 4c3e23f529b581c3cbe95350e84e66e3cb05704f ... commit 16b373a96b0a353f7454b141f7aa6f548c979d0a ...次のようにして、正しいバージョンのリポジトリの一番上に正しいコミットを適用します。
チェリーピックを使用すること（既存のいくつかのコミットによってもたらされた変更）
git cherry-pick ec59ab844cf504e462f011c8cc7e5667ebb2e9c7あるいはコミット範囲をチェリーピッキングすることで：
マージする前に、まず正しい変更を確認します。
git diff 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704fマージする前に、まず正しい変更を確認します。
git cherry-pick 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704fこれはあなたがコミットした正しいコミットの範囲です（誤ってコミットされたマージを除く）。
複数の方法で実行できます。
1）マージの中止
間違ったマージ（間違えたブランチで誤って行われた）の中間にあり、マージを回避して最新のブランチに戻るには、次のようにします。
git merge --abort
2）HEADをリモートブランチにリセット
リモート開発ブランチから作業している場合は、次のようにHEADをリモートブランチの最後のコミットにリセットできます。
git reset --hard Origin/develop
）現在のブランチを削除し、リモートリポジトリから再度チェックアウトします
あなたがリモート/開発ブランチと同期するローカルリポジトリで開発ブランチに取り組んでいると考えると、以下のようにできます：
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 stashgit branch -d the_local_branchgit checkout -t <name of remote>git stash apply
これは私のために働いた..！
新しいブランチを作成してから、必要なコミットをチェリーピックします。
上記の多くの回答で説明されているように、そのセーバーとシンプルなリセット
この場合、あなたはブランチをgit reset --hard <branch_name>でリセットしたいでしょう。再設定する前に変更を保存したい場合は、必ず新しいブランチとgit checkout <branch_name>を作成してください。
git reset --hard <commit_id>を使って状態を特定のコミットにリセットすることもできます。
変更がプッシュされている場合は、代わりにgit revert <branch_name>を使用できます。他のシナリオでも git revertとgit checkout の使い方を必ずチェックしてください。
マージの直後に元に戻す必要があり、マージの試行後に他に何もしていないことに気付いた場合は、次のコマンドを発行することができます： git reset --hard HEAD@{1}。
基本的に、マージ後に他に何もコミットされていない場合、マージshaはHEAD@{0}を指しているため、HEAD@{1}はマージ前の前のポイントになります。