「マージした瞬間、間違いに気づいた…！」
Gitを使って開発していると、そんな冷や汗ものの経験をしたことはありませんか？
特にgit mergeはブランチを統合する重要な操作ですが、一度間違えると履歴がぐちゃぐちゃになり、チーム全体の進行にも影響してしまうことがあります。
「pushする前なら戻せる？」「リモートに反映してしまった場合は？」「revertとreset、どちらを使えば安全？」――こうした疑問を抱えながら、焦って検索している方も多いでしょう。
Gitのマージ取り消しは、状況（push前か後か・誤マージの範囲・チーム環境）によって最適な方法が変わります。誤った操作をすれば、他メンバーの作業を巻き込んでしまうリスクも。
しかし正しい手順を理解していれば、履歴を壊さず安全に「なかったこと」にできるのです。
この記事では、git mergeを取り消したいすべての開発者に向けて、シーン別・目的別に最適な方法をわかりやすく整理しました。
もう「どのコマンドを使えばいいのか」で迷う必要はありません。
格安ドメイン取得サービス─ムームードメイン─
git mergeを取り消す前に理解すべき基本と注意点
git mergeを間違えた時の代表的な取り消し方法一覧（reset, revert, reflog）
誤ってgit mergeを実行してしまい、今すぐ元に戻したい時、Gitには主に3つのコマンドを使った取り消し方法があります。状況と目的に応じて最適な方法を選ぶことが、安全に作業を復旧させるための第一歩です。
| コマンド | 特徴 | 使用推奨シーン | 履歴への影響 | 危険度 |
|---|---|---|---|---|
git reset | 履歴をなかったことにする。最もシンプルだが強力。 | ローカル環境（プッシュ前）で、自分の作業を巻き戻したい時。 | 過去のコミットが消去され、履歴が書き換わる。 | 高（チーム開発でのプッシュ後は厳禁） |
git revert | マージ操作を打ち消す新しいコミットを作成する。 | リモートにプッシュした後、または共有ブランチの変更を取り消したい時。 | マージを取り消すための新しいコミットが残り、履歴は残る。 | 低（最も安全な方法） |
git reflog | 過去に行ったすべての操作履歴を表示し、特定の状態に戻る。 | resetやrevertでミスした時や、コミットハッシュが分からない時の最終手段。 | 参照ログを参照してブランチを移動させる。 | 中（強力だが、コミットハッシュの特定が必要） |
git resetとgit revertの違いと選び方／履歴改変リスク
マージを取り消す際に最も重要な判断ポイントは、「その変更を既にリモートリポジトリにプッシュしたかどうか」、そして「履歴を書き換えても良いか」です。
1. git reset (履歴を消し去る危険な方法)
git resetは、指定したコミット以降の履歴を「なかったこと」にします。ローカルで作業している限り非常に便利ですが、既にリモートにプッシュされている共有の履歴に対して実行し、その後に強制プッシュ（git push -f）をすると、他のチームメンバーの履歴との整合性が崩れ、深刻なコンフリクト（競合）や作業の喪失を引き起こします。
チームで共有しているブランチ（mainやdevelopなど）にプッシュした後は、git resetを使った履歴の書き換えは絶対に避けてください。使って良いのは、自分が作業しているだけのローカル環境、かつプッシュ前に限られます。
2. git revert (履歴を残す安全な方法)
git revertは、取り消したいコミットの変更内容を打ち消すための新しいコミットを作成します。履歴自体は消えませんが、「Aというマージをした、その直後にAを取り消すBというコミットをした」という流れが残り、履歴の整合性は完全に保たれます。
- 安全性: チームメンバーの作業に悪影響を与えず、プッシュ後でも安全に使えます。
- 推奨: 原則として、共有ブランチのマージ取り消しには
git revertを選択するのがプロのベストプラクティスです。
merge commitの取り消し手順と履歴をきれいに保つコツ
git revertを使ってマージを取り消す際、通常のコミットとは異なる重要な手順が必要です。マージコミットは通常、複数の親コミット（マージ元とマージ先）を持つため、Gitに対して「どの親コミットの状態に戻したいか」を明示的に指示しなければなりません。
この指示に使うのが、-m <親の番号>オプションです。
1.マージコミットのハッシュ値を確認する
git log --oneline
# （例:abcde12 Merge branch 'feature/A'）2.取り消しコマンドを実行する
git revertを実行する際は、取り消し操作を行っているブランチ（現在のブランチ）の元の親を1番として指定します。通常はマージされたブランチの変更を打ち消したいため、1を指定します。
# 書式：git revert -m <親の番号> <マージコミットのハッシュ値>
git revert -m 1 abcde12これにより、マージされた変更が打ち消された新しいコミットが作成され、マージ前の状態に戻ります。
【履歴をきれいに保つコツ】
git revertは履歴に「取り消しコミット」が残ります。これが煩雑だと感じる場合でも、マージの取り消しは可読性の確保が最優先です。新しいコミットメッセージを編集する際は、「Revert “Merge branch ‘feature/A'”」のように、何を取り消したのかが明確に分かるように記述しましょう。
将来的にこのマージを再実行する可能性がある場合は、git revertで取り消したコミットをさらにgit revertで再々反転させることで、変更を元に戻すことができます。これがgit resetではできない、履歴保持の大きなメリットです。
シーン別git merge取り消し完全ガイド
ローカルだけで取り消す場合（push前のreset／abort）
まだ変更をリモートリポジトリにプッシュしていない場合は、最も簡単かつ強力なgit resetコマンドを使用できます。これは「履歴をなかったことにする」操作であり、プッシュ前であれば他のメンバーに影響を与えません。
| 状況 | コマンド | 動作 |
|---|---|---|
| 直前のマージを取り消す | git reset --hard HEAD^ | マージコミットを完全に削除し、マージ前の状態に戻します。マージ後に加えたローカルのコミットもすべて消えます。 |
| マージ操作中（コンフリクトで停止中） | git merge --abort | マージ作業全体を中断し、マージ開始前の状態に完全に復元します。 |
【手順：git reset --hard HEAD^を使用】
1.現在の状態を確認：
git status 作業ディレクトリに未コミットの変更がないことを確認します。ある場合は git stash で一時退避してください。
2.マージを取り消す：
git reset --hard HEAD^ HEAD^ は「現在のコミット（マージコミット）の1つ前のコミット」を指します。これにより、マージコミットは完全に消去され、コードと履歴がマージ前の状態に戻ります。
pull・push後にリモート含めて取り消す場合（履歴保持・影響最小化）
既にリモートリポジトリ（GitHubなど）にプッシュしてしまった場合、または共有ブランチで作業している場合は、**git revert**が唯一にして最も安全な選択肢です。履歴を書き換えないため、他のメンバーの作業を壊すリスクをゼロにできます。
【手順：git revert -m 1を使用】
1.取り消したいマージコミットのハッシュ値を確認：
git log --onelineマージコミットは「Merge…」というメッセージになっています。その先頭のハッシュ値（例: a1b2c3d）をコピーします。
2.git revertで取り消しコミットを作成：
# 書式: git revert -m <親の番号> <マージコミットのハッシュ値>
git revert -m 1 a1b2c3dm 1は、現在のブランチ（マージされた側のブランチ）を親として、その状態に戻ることを指示する重要なオプションです。
3.コミットメッセージを編集：
エディタが立ち上がったら、取り消しであることが明確に分かるメッセージ（例: Revert “Merge feature/bugfix”）を確認して保存・終了します。
4.リモートにプッシュ：
git push origin <ブランチ名>これで、マージを打ち消す「新しいコミット」がリモートに反映され、他のメンバーはgit pullするだけで安全に取り消しが適用されます。
main・develop等、重要ブランチの誤マージを元に戻す安全な方法
mainやdevelopといった本番環境に直結するブランチでの誤マージは、一刻を争う緊急事態です。この場合も、原則としてgit revert以外の選択肢はありません。履歴の改変は絶対に行わず、チームへの影響を最小限に抑えることが最優先です。
Fast-Forwardマージの場合の注意点
通常、Pull Request（PR）経由のマージはマージコミット（Non-ff）になりますが、ローカルでgit mergeを実行したり、GitHubの設定によってはFast-Forward (ff) マージが実行されることがあります。ffマージはマージコミットを作成しないため、git revert -m 1が使えません。
ffマージを取り消す場合は、以下の手順で、マージされた直前のコミットに戻る必要があります。
1.マージ前のコミットハッシュを確認：
ffマージが行われた直前のコミットのハッシュ値（例: x1y2z3a）を特定します。
2.安全なresetで取り消し（要プッシュ前）：
もしそのマージがまだプッシュされていなければ、以下のコマンドで取り消せます。
# ffマージを取り消したいコミットIDの直前に戻る
git reset --hard x1y2z3a3.プッシュ後のffマージを取り消す場合は？
プッシュ後にffマージを取り消す必要がある場合は、git revertを複数回実行し、マージに含まれていたすべてのコミットを一つずつ打ち消すという、非常に手間のかかる作業が必要になります。この状況を避けるためにも、重要ブランチではGitHubやGitLabの設定で必ずマージコミットを作成（No fast-forward）するように設定しておくことが、最大の再発防止策となります。
あなたのサイトのURL、そろそろスリムにしませんか？
失敗状況ごとのリカバリーと再発防止策
mainやdevelopに誤マージ！重要ブランチで絶対失敗しない取り消し手順
mainやdevelopといったチームの核となるブランチへの誤マージは、本番環境への影響リスクが非常に高いため、履歴の改変（reset）は絶対に避け、必ずgit revertを使用します。
1.落ち着いてマージコミットを特定する:
まず、誤ってマージされたコミットのハッシュ値を正確に把握します。
git log --oneline（例：abcde12 Merge branch 'feature/risk'）
2.git revertコマンドを実行する:
マージコミットを打ち消す新しいコミットを作成します。-m 1オプションを忘れずに指定します。
# 現在のブランチ（mainやdevelop）にチェックアウトしていることを確認
git checkout main
# マージを取り消すためのリバートコミットを作成
git revert -m 1 abcde12これにより、マージ前のコード状態に戻るための新しいリバートコミットが作成されます。
3.安全にリモートへプッシュする:
この新しいコミットをリモートにプッシュすることで、他のメンバーも影響なく最新の状態に追従できます。
git push origin mainポイント: この手順は、チームメンバーに「履歴を巻き戻した」という混乱を与えず、「マージされたが、すぐに取り消された」という事実を履歴に残すため、透明性と安全性が最も高い方法です。
コンフリクト発生時のgit merge --abortと復旧手順
git mergeを実行した結果、大量のコンフリクト（競合）が発生し、「もうマージ自体やめたい！」となった場合は、解決作業に入る前にすぐに中断できます。
1.コンフリクト状態を確認する:
git status 大量のファイルが「unmerged」になっていることを確認します。
2.マージ操作を中止する:
マージの最中に実行することで、マージ操作を始める前の状態にワークツリーとインデックスをリセットします。
git merge --abort 注意: git merge --abort は、マージ操作を開始してから一度もコミットをしていない場合にのみ有効です。
3.復旧の確認:
再度git statusを実行し、「nothing to commit, working tree clean」と表示されれば復旧完了です。その後、落ち着いてブランチ戦略を見直し、再度マージの準備を進めましょう。
【不要なパソコンを送るだけ】パソコン無料処分サービス『送壊ゼロ』
reflogで混乱した状態から復旧する手順
git resetを間違えて実行してしまったり、どこに戻るべきか分からなくなったりした場合でも、git reflogを使えばGitがローカルで行った操作の全履歴から、正しい時点を見つけて復旧できます。これはGitにおける「保険」のような存在です。
1.リファレンスログを確認する:
git reflog実行すると、HEAD@{0}から過去に遡る形で、コミット、マージ、リセットなど、すべての操作ログが表示されます。
例：
abcde12 (HEAD -> main) HEAD@{0}: merge feature: Merge branch 'feature'
fghij34 HEAD@{1}: commit: Add new feature
klmno56 HEAD@{2}: checkout: moving from feature/bug to main2.戻りたい状態のハッシュ値を特定する:
上記の例で、マージ操作（HEAD@{0}）の直前の状態（fghij34）に戻したいと判断します。
3.安全に強制リセットする:
特定のハッシュ値に強制的に戻ります。これは履歴を巻き戻す危険な操作ですが、reflogで明確に状態を特定できているため安全性が確保されます。
git reset --hard abcde12 （abcde12を、戻りたいマージ前のコミットハッシュに置き換えてください。）
GitHub／GitLab連携：PR（Pull Request）／MR取り消しとRevert PRの作成方法
GitHubやGitLabなどのプラットフォーム上では、マージ操作を取り消すためのGUI機能が提供されています。コマンドラインを使わず、最も直感的に安全なgit revert操作を実行できるため、この方法を推奨します。
GitHubでの手順
- Pull Requestページにアクセス: マージされたPull Requestのページを開きます。
- 「Revert」ボタンをクリック: PRがマージされたセクションの近くに表示されている「Revert」ボタンをクリックします。
- 新しいPRを作成: GitHubが自動的にマージを打ち消す変更（git revert相当）を含む新しいブランチを作成し、そのブランチへのPull Request作成画面に遷移します。
- Revert PRをマージする: この新しい「Revert PR」を通常通りレビューし、マージすることで、元の誤マージが安全に取り消されます。
GitLabでの手順
- Merge Requestページにアクセス: マージされたMerge Request（MR）のページを開きます。
- 「Revert」ボタンをクリック: マージされたことを示す表示の近くにある「Revert」ボタンをクリックします。
- ターゲットブランチを選択: リバートコミットを作成するターゲットブランチ（通常はマージされたブランチ）を選択します。
- Revertコミットを作成: GitLabが自動的にリバートコミットを作成・プッシュするか、または新しいMRを作成するかを選択します。これにより、安全に取り消しが実行されます。
よくある質問（FAQ)
-
VSCodeやSourceTreeなどGUIツールでの
merge取り消し手順は？ -
コマンドライン操作に慣れていない方や、視覚的に操作したい方は、GUIツールを使うのが最も直感的です。
VS Code (Git Graph拡張機能などを使用)
- VS CodeのGit Graphビュー（Git履歴表示）を開きます。
- 取り消したいマージコミットを探して右クリックします。
- メニューから「Revert Commit」（コミットの取り消し）を選択します。
- VS Codeが自動的に
git revertコマンドを実行し、取り消し用の新しいコミットを作成してくれます。
SourceTree
- SourceTreeの履歴タブを開き、取り消したいマージコミットを探します。
- そのコミットを右クリックし、「コミットをリバート」を選択します。
- マージコミットの場合、親コミットを選択するダイアログが表示されるので、「メインラインの親」（通常は
1番）を選択します。 - 新しいリバートコミットが作成されるので、通常通りプッシュしてリモートに反映させます。
-
ファイル単位でマージを取り消す（部分的リセット）方法は？
-
誤マージで影響を受けたファイルがごく一部で、他のファイルの変更は残したい場合、全体を巻き戻す
resetやrevertは不適切です。以下の手順で、特定のファイルだけをマージ前の状態に戻すことができます。1.現在のHEAD（最新コミット）から、特定のファイルだけをステージングエリアに戻す:
git reset HEAD^ -- path/to/target/file.txtこの操作は、
git resetをファイルパス付きで使うことで、ファイルの内容だけを一つ前のコミットの状態に戻し、ステージングエリアに置きます。2.ワーキングツリーのファイルを更新する:
もしワーキングツリー（実際のファイル）も元に戻したい場合は、さらにチェックアウトを実行します。
# 特定ファイルを一つ前のコミットの状態に戻す git checkout HEAD^ -- path/to/target/file.txtこの方法で特定ファイルをマージ前の状態に戻した後、新しいコミットとしてコミットし直し、リモートにプッシュすることで、部分的な取り消しが完了します。
-
git pullでマージが走った場合の取り消し方は？ -
git pullは「git fetch」と「git merge」を連続で実行するコマンドです。予期せずpullでマージが走り、コンフリクトしたり、意図しない変更が取り込まれた場合は、直前のマージを取り消す操作で復旧できます。1.コンフリクトで止まった場合:
pull実行中にコンフリクトが発生したら、すぐに以下のコマンドで中断してください。
git merge --abort2.マージが完了してしまった場合（ローカル）:
まだプッシュしていなければ、直前のマージコミットをgit resetで消去します。
git reset --hard HEAD^git pullは予期せぬマージを引き起こしやすいため、トラブルを避けたい場合は、git pullの代わりにgit fetchとgit merge --no-ffを分けて実行するか、git pull --rebaseを使うことを検討しましょう。
-
今後同じミスをしないための再発防止策は？
-
マージミスは誰でも起こり得ますが、チーム開発では事前にミスを防ぐ仕組みを導入することが極めて重要です。
1. 保護ブランチの設定 (GitHub/GitLab/Bitbucket)
mainやdevelopなどの重要なブランチに対し、以下の制限を設定します。- マージにPR（MR）の作成を必須にする
- マージ前に複数のレビュアーによる承認を必須にする
- 管理者権限を持つユーザー以外からの直接プッシュを禁止する
2. Fast-Forwardマージの禁止
重要ブランチのマージ設定で、必ずマージコミットを作成する設定（Non-Fast-Forward）にします。これにより、マージ取り消しが必要になった際に、安全な
git revert -m 1コマンドが常に使える状態を確保できます。3. 作業前チェックリストの徹底
マージ作業に取り掛かる前に、「今いるブランチは正しいか？」「マージするブランチは最新か？」「CI/CDが通っているか？」を声に出して確認する習慣をチームで導入しましょう。
まとめ
本記事では、「git merge 取り消し」という緊急性の高い問題に対し、安全性と確実性を最優先にした具体的な解決手順を解説しました。
最も重要な点は、「プッシュしたかどうか」で取るべき行動が明確に分かれるということです。
| 状況 | 推奨コマンド | 履歴への影響 |
|---|---|---|
| プッシュ前（ローカル） | git reset --hard HEAD^ | 履歴を消去（最も簡単だが危険） |
| プッシュ後（リモート） | git revert -m 1 <ハッシュ> | 打ち消しコミット作成（最も安全） |
| コンフリクトで停止中 | git merge --abort | マージ操作自体を中止 |
| 履歴が混乱した時 | git reflog | 過去の操作から復旧ポイントを探す |
Gitの操作は、特に履歴を書き換える際は緊張を伴いますが、git revertという安全な手段が用意されています。重要ブランチへのマージ取り消しは、必ずこのrevert機能を使い、チームの作業履歴を壊さないように徹底しましょう。
今回の経験を活かし、GitHub/GitLabでの保護ブランチ設定やFast-Forwardマージの禁止など、再発防止策をチームで導入することで、より安心で効率的な開発体制を築くことができます。
