git commit（コミット）の取り消し方｜push前後の早見表・NG操作・復元

push 前は git reset のオプションで変更の残し方（ステージ・ファイル・消す）を選び、push 後は git revert で打ち消します。

flowchart TD
    A{push済み？} -- はい --> F[revert HEAD]
    A -- まだ --> B[reset HEAD~1]
    B --> C[--soft<br>変更を残す]
    B --> E[--hard<br>変更も消す]

push 後に履歴を書き換えて強制 push すると、同じブランチに入っていた他の人のコミットまで消えることがあります。この記事では、その様子も含めて、使い捨てのリポジトリで各ケースを実際に動かし、git log と git status の前後の出力をそのまま載せました。

状況別の早見表（やりたいこと×push前/後）

自分の状況の行を見ると、1行のコマンドと「実行後に何が残るか」が分かります。

push したかどうか分からないときは、git status -sb の1行目を見ます（後述）。[ahead 1] と出ていれば、まだ push していないコミットが1件あります。

この記事と関連記事の分担

「取り消し」はケースが多いため、この記事を入口にして、詳しい手順は次の記事に分けています。

確認環境：Git 2.43.0（Linux）。使い捨てのリポジトリと、ローカルに作った bare リポジトリ（リモートの代わり）で、この記事のコマンドを実行し、出力を英語表示（LANG=C）のまま載せています。コミットIDは実行のたびに変わります。出力中のリモートのパスは <remote> と表記しています。オプションの仕様は Git 公式マニュアル（git-scm.com、最新版 2.56 系）、VS Code の操作は VS Code 公式ドキュメントで確かめました（確認日 2026年10月14日）。

まず確認：そのコミットは push 済みか

取り消し方を決める前に、push 済みかどうかを確かめます。

$ git status -sb
## main...origin/main [ahead 2]

$ git log --oneline origin/main..HEAD
346b9a8 feat: 注文詳細を追加
1ee5832 feat: 注文一覧を追加

git log --oneline origin/main..HEAD は「リモートに無く、手元にだけあるコミット」の一覧です。ここに出るコミットだけが、履歴を書き換えても他の人に影響しない範囲です。

push前：直前のコミットを取り消す（git reset）

git reset は、ブランチの先端を前のコミットに戻すコマンドです。HEAD~1 は「今のコミットの1つ前」を表します。オプションで、取り消したコミットの変更をどこに残すかが変わります。

--soft：コミットだけ取り消し、すぐ commit し直す

$ git log --oneline
b224b98 feat: 機能Cを追加
1b486f9 feat: 機能Bを追加
fe04cb3 init: app.txt を追加

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

$ git reset --soft HEAD~1

$ git log --oneline
1b486f9 feat: 機能Bを追加
fe04cb3 init: app.txt を追加

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app.txt

コミットは消え、変更は Changes to be committed（ステージ）に残りました。ahead 1 が up to date に変わったことから、push 前の1件だけが取り消されたことも分かります。

--mixed（省略時）：add からやり直す

$ git reset HEAD~1
Unstaged changes after reset:
M   app.txt

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   app.txt

no changes added to commit (use "git add" and/or "git commit -a")

変更は Changes not staged for commit に移りました。ファイルの中身は残っているので、必要なものだけ add し直せます。

--hard：変更ごと消す

$ git reset --hard HEAD~1
HEAD is now at 1b486f9 feat: 機能Bを追加

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

--hard は、コミットしていない変更も一緒に消します。 消したコミットは後述の reflog で戻せますが、一度もコミットしていない変更は戻せません。

取り消したコミットのメッセージを使い回す

公式マニュアルの例にある書き方です。reset の直前の位置は ORIG_HEAD に記録されるので、そのメッセージで commit し直せます。

$ git reset --soft HEAD~1
$ git commit -C ORIG_HEAD
[main 66ba633] fxi: typo
 Date: Wed Oct 14 01:13:23 2026 +0900
 1 file changed, 1 insertion(+)

-C はメッセージをそのまま使い、-c はエディタで直してから使います。

push前：複数のコミットをまとめて取り消す

HEAD~3 で直前の3件をまとめて取り消せます。--soft なら3件分の変更がステージに残るので、1件のコミットにまとめ直すこともできます。

$ git log --oneline
b30c121 feat: 機能Fを追加
9583aeb feat: 機能Eを追加
a6e2c6c feat: 機能Dを追加
1b486f9 feat: 機能Bを追加
fe04cb3 init: app.txt を追加

$ git reset --soft HEAD~3

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app.txt

$ git commit -q -m "feat: 機能D〜Fを追加"

$ git log --oneline
a743ae3 feat: 機能D〜Fを追加
1b486f9 feat: 機能Bを追加
fe04cb3 init: app.txt を追加

途中の1件だけを消したい・直したいときは、git rebase -i HEAD~5 を使います。一覧の pick を drop（削除）・reword（メッセージ修正）・edit（内容修正）に変えます。手順は関連記事「git rebase -iでコミットをまとめる｜squash・fixup早見表と復旧」で扱っています。

push前：直前のコミットを直す（git commit --amend）

取り消すより、直前のコミットを直したいだけなら --amend が向いています。

$ git commit --amend -m "feat: 注文詳細画面を追加"
[main f986360] feat: 注文詳細画面を追加
 Date: Wed Oct 14 01:11:59 2026 +0900
 1 file changed, 1 insertion(+)

amend は元のコミットを新しいコミットに置き換えるため、コミットIDが変わります。 push 済みのコミットに使うと、次の push が rejected になります。ファイルの追加忘れ（--no-edit）や push 後の amend の扱いは、関連記事「git addの取り消し方｜1ファイル・全部・commit後の早見表と復元」で扱っています。

amend を取り消す

amend の前のコミットも reflog に残っています。

$ git reflog -3
f986360 HEAD@{0}: commit (amend): feat: 注文詳細画面を追加
44a2692 HEAD@{1}: reset: moving to HEAD@{1}
0e1536a HEAD@{2}: reset: moving to HEAD~2

$ git reset --soft "HEAD@{1}"

$ git log --oneline -1
44a2692 feat: 注文詳細を追加

HEAD@{1} は「1回前の操作のときに HEAD があった場所」です。zsh などでは {} が展開されることがあるため、引用符で囲むと確実です。

commit 前：add を取り消す・ファイルの変更を捨てる

$ git add .

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app.txt
    new file:   secret.env

$ git restore --staged secret.env

$ git status --short
M  app.txt
?? secret.env

$ git restore --staged .

$ git status --short
 M app.txt
?? secret.env

git status --short の左の列はステージ、右の列は作業中のファイルの状態です。M が M に変わり、add だけが外れたことが分かります。ファイルの中身は残ります。

git restore は Git 2.23 で加わったコマンドです。最初のコミット前に restore --staged がエラーになる例や、git reset との違いは、関連記事「git addの取り消し方｜1ファイル・全部・commit後の早見表と復元」で扱っています。

push後：コミットを打ち消す（git revert）

push 済みのコミットは、履歴を消さずに「逆の変更」を新しいコミットとして足す git revert で取り消します。他の人の手元の履歴と食い違わないため、共有ブランチではこの方法が基本です。

$ git log --oneline -3
10fb6a8 feat: 機能Hを追加
a743ae3 feat: 機能D〜Fを追加
1b486f9 feat: 機能Bを追加

$ git revert --no-edit HEAD
[main 33c2471] Revert "feat: 機能Hを追加"
 Date: Wed Oct 14 10:00:00 2026 +0900
 1 file changed, 1 deletion(-)

$ git log --oneline -4
33c2471 Revert "feat: 機能Hを追加"
10fb6a8 feat: 機能Hを追加
a743ae3 feat: 機能D〜Fを追加
1b486f9 feat: 機能Bを追加

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

$ git push origin main
To <remote>
   10fb6a8..33c2471  main -> main

元のコミット 10fb6a8 は履歴に残り、その上に打ち消しコミット 33c2471 が乗りました。push は通常の push（fast-forward）で通ります。--no-edit を外すと、メッセージを編集するエディタが開きます。

複数のコミットを1つの revert にまとめる

$ git revert --no-commit HEAD~3..HEAD

$ git status --short
D  f1.txt
D  f2.txt
D  f3.txt

$ git commit -q -m "revert: f1〜f3を取り消し"

$ git log --oneline -5
9fb4929 revert: f1〜f3を取り消し
ecc4e31 feat: f3
d4d40d1 feat: f2
5c9a904 feat: f1
44a2692 feat: 注文詳細を追加

HEAD~3..HEAD は「HEAD~3 より後の3件」です。--no-commit を付けないと、1件ごとに revert コミットが3つできます。

push 後に reset だけして push するとどうなるか

$ git reset --hard HEAD~1
HEAD is now at 10fb6a8 feat: 機能Hを追加

$ git push origin main
To <remote>
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '<remote>'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

$ git status
On branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

リモートには取り消したはずのコミットが残っているため、push は拒否されます。ここで git pull すると取り消したコミットが戻り、--force すると次の節の事故につながります。push 後の取り消しは revert を使うと、この分かれ道に入らずに済みます。

revert のコンフリクトの対処や --abort は、関連記事「git revertの使い方｜resetとの違いとマージコミット取り消し手順」で扱っています。

push後：マージコミットを取り消す（revert -m 1）

マージコミットには親が2つあるため、-m で「どちらの親に戻すか」を指定しないと revert できません。

$ git log --oneline --graph
*   0eecc12 Merge branch 'feature'
|\  
| * 0d23118 feat: 新機能
* | 5c32f15 fix: main側の修正
|/  
* 65d20b6 init

$ git revert HEAD
error: commit 0eecc123722b59ed45fb13be4d81a79ae5e0dbb1 is a merge but no -m option was given.
fatal: revert failed

$ git revert -m 1 --no-edit HEAD
[main 370301b] Revert "Merge branch 'feature'"
 Date: Wed Oct 14 01:11:26 2026 +0900
 1 file changed, 1 deletion(-)
 delete mode 100644 feature.txt

-m 1 は1番目の親（マージを受け入れた側、ここでは main）を基準にする指定です。feature ブランチで足した feature.txt が消え、main 側の修正は残りました。

注意：revert したマージは、もう一度マージしても戻らない

公式マニュアルでは、マージの revert は「そのマージで入った変更を今後は要らないと宣言すること」と説明されています。実際に試すと次のようになります。

$ git log --oneline -2
280b949 Revert "Merge branch 'feature'"
8a54619 Merge branch 'feature'

$ git merge feature
Already up to date.

$ ls
app.txt

feature ブランチのコミットはすでに main の履歴に含まれているため、Git は「取り込み済み」と判断し、feature.txt は戻りません。feature 側で修正を足してから再マージした場合も、Git 2.43.0 では CONFLICT (modify/delete) になりました。

取り込み直すには、revert のコミットをさらに revert します。

$ git revert --no-edit HEAD
[main 0f0a496] Reapply "Merge branch 'feature'"
 Date: Wed Oct 14 01:11:41 2026 +0900
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

$ git log --oneline -4
0f0a496 Reapply "Merge branch 'feature'"
280b949 Revert "Merge branch 'feature'"
8a54619 Merge branch 'feature'
c070e0b fix: main側の修正

revert を revert したときの既定メッセージは、Git 2.43 から Reapply "..." になりました（リリースノートでは「revert を記録したコミットを revert するときの既定のメッセージを調整した」とあります）。

push 前なら ORIG_HEAD でマージをなかったことにできる

$ git log --oneline --graph
*   6ab2cd4 Merge branch 'topic'
|\  
| * ad7fbc8 topic
* | b9b7c37 main2
|/  
* d3850ca init

$ git reset --hard ORIG_HEAD
HEAD is now at b9b7c37 main2

$ git log --oneline --graph
* b9b7c37 main2
* d3850ca init

git merge や git pull は、実行前のブランチの先端を ORIG_HEAD に残します。マージ直後で、まだ push していなければ、この1行で戻せます。ただし、その後に reset などを実行すると ORIG_HEAD は上書きされます。

やってはいけない操作：force push で他人のコミットが消える

push 後に reset して git push --force すると、リモートは手元の状態で上書きされます。その間に他の人が push していたコミットも消えます。 alice と bob の2人で同じ main を使う例で確かめました。

# bob が「feat: bobの作業」を push した後のリモート
$ git log --oneline
706c771 feat: bobの作業
1b7d97d feat: C（取り消したい）
dd54b59 feat: B
bcaac5d init

# alice は bob の push を取得していない
$ git log --oneline
1b7d97d feat: C（取り消したい）
dd54b59 feat: B
bcaac5d init

$ git reset --hard HEAD~1
HEAD is now at dd54b59 feat: B

$ git push --force-with-lease origin main
To <remote>
 ! [rejected]        main -> main (stale info)
error: failed to push some refs to '<remote>'

$ git push --force origin main
To <remote>
 + 706c771...dd54b59 main -> main (forced update)

--force-with-lease は「リモートが、最後に取得したときから変わっていない場合だけ上書きする」オプションです。bob の push があったので stale info で止まりました。一方 --force は止まらずに上書きし、bob 側から見るとこうなります。

$ git fetch
From <remote>
 + 706c771...dd54b59 main       -> origin/main  (forced update)

$ git log --oneline origin/main
dd54b59 feat: B
bcaac5d init

bob のコミット 706c771 はリモートから消えました。 bob の手元には残っているため、bob が push し直せば戻りますが、気づかなければそのまま失われます。

--force-with-lease も fetch の後は止まらない

--force-with-lease は、手元の origin/main（最後に取得したリモートの状態）と比べるだけです。上書きする前に git fetch していると、他の人のコミットを見ていなくても通ってしまいます。

# bob が push した後、alice が fetch だけしてから強制 push
$ git fetch
From <remote>
   dd54b59..33e0bb9  main       -> origin/main

$ git push --force-with-lease origin main
To <remote>
 + 33e0bb9...add3ebd main -> main (forced update)

$ git log --oneline origin/main
add3ebd feat: D
dd54b59 feat: B
bcaac5d init

bob のコミット 33e0bb9 が消えました。公式マニュアルも、エディタなどが裏で自動的に fetch する環境では --force-with-lease 単体の保護が効かなくなると注意しています。

これを防ぐのが --force-if-includes（Git 2.30 で追加）です。 リモートの先端が、手元のブランチの reflog に一度でも含まれていたか（＝取り込んで確かめたか）を調べます。

$ git fetch
From <remote>
   8877a64..53ea497  main       -> origin/main

$ git push --force-with-lease --force-if-includes origin main
To <remote>
 ! [rejected]        main -> main (remote ref updated since checkout)
error: failed to push some refs to '<remote>'
hint: Updates were rejected because the tip of the remote-tracking branch has
hint: been updated since the last checkout. If you want to integrate the
hint: remote changes, use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

fetch した後でも、取り込んでいないので止まりました。毎回付けるなら git config --global push.useForceIfIncludes true で既定にできます。

やってはいけない操作の一覧

GitHub では、保護されたブランチへの force push は既定でブロックされます（ブランチ保護の「Allow force pushes」で許可した場合を除く）。main などの共有ブランチには保護を設定しておくと、上の事故を仕組みで防げます。

API キーなどの秘密情報を push してしまった場合は、履歴を書き換えるより先に、そのキーを無効化します。手順は関連記事「APIキーをGitHubにpushしてしまった時の対処手順」で扱っています。

間違えたときの復元：git reflog

git reflog は、HEAD が動いた記録の一覧です。reset・amend・rebase で見えなくなったコミットも、ここから探せます。

$ git status --short
 M app.txt
A  wip.txt

$ git reset --hard HEAD~2
HEAD is now at 0e1536a init

$ git log --oneline
0e1536a init

$ git reflog -5
0e1536a HEAD@{0}: reset: moving to HEAD~2
44a2692 HEAD@{1}: commit: feat: 注文詳細を追加
1323e7b HEAD@{2}: commit: feat: 注文一覧を追加
0e1536a HEAD@{3}: commit (initial): init

$ git reset --hard "HEAD@{1}"
HEAD is now at 44a2692 feat: 注文詳細を追加

$ git log --oneline
44a2692 feat: 注文詳細を追加
1323e7b feat: 注文一覧を追加
0e1536a init

2件のコミットは戻りました。一方、reset --hard の前にあった作業中の変更（M app.txt と、add しただけの wip.txt）は戻っていません。

add だけしていたファイルは fsck で探せる

add したファイルの中身は、Git の内部にオブジェクト（blob）として保存されています。どこからも参照されなくなった blob は git fsck で見つかります。

$ git fsck --lost-found
dangling blob e7123041ee0458f44072ab4c5f267fd370f831f0

$ git show e7123041ee0458f44072ab4c5f267fd370f831f0
wip

ファイル名は残らないため、中身を見て判断します。add もしていなかった変更（この例の app.txt の追記）は、Git のどこにも記録がなく、取り戻せませんでした。

reflog の記録の保存期間は、公式マニュアルでは既定で90日、今のブランチから到達できなくなった記録（reset や amend で外れたもの）は30日です。reflog の見方やブランチごとの reflog、reset --hard からの復元の詳しい手順は、関連記事「git reset --hardを取り消す方法｜reflogで復元する手順」で扱っています。

VS Code での取り消し操作

VS Code のソース管理ビューにも、同じ取り消し操作があります。VS Code 公式ドキュメントでの名前と、対応する Git の操作は次のとおりです。

• Undo Last Commit は push していないコミットに使う操作で、ドキュメントでは「変更はステージに残る」と説明されています（git reset --soft HEAD~1 の後と同じ状態）。最初のコミットを取り消した場合は、ファイルが未追跡（Untracked）に戻ります。
• Discard Changes で捨てた変更は、ドキュメントでも「ごみ箱には移らない」と注意されています。
• push 済みのコミットについて、ドキュメントはターミナルで git revert --no-edit <コミットID> を実行する方法を案内しています。

よくある質問

Q. git commit を取り消すには？（push 前） A. 変更を残すなら git reset --soft HEAD~1、変更ごと消すなら git reset --hard HEAD~1 です。メッセージを直したいだけなら git commit --amend -m "..." を使います。

Q. git commit を push 後に取り消すには？ A. git revert <コミットID> で打ち消しのコミットを作り、通常どおり push します。直前のコミットなら git revert HEAD です。履歴そのものを消すのは、自分しか使っていないブランチに限り、--force-with-lease --force-if-includes を付けて push します。

Q. git push を取り消すことはできますか？ A. push という操作そのものを取り消すコマンドはありません。push したコミットを revert で打ち消すか、履歴を書き換えて強制 push するかのどちらかです。共有ブランチでは revert を使います。

Q. git add を取り消すには？（commit 前） A. git restore --staged <ファイル>（全部なら git restore --staged .）です。ファイルの変更は残ります。最初のコミット前は git rm --cached <ファイル> を使います。

Q. git reset --hard を取り消せますか？ A. コミット済みの内容なら git reflog で元の位置を探し、git reset --hard "HEAD@{1}" などで戻せます。コミットしていなかった変更は戻せません（add だけしていたファイルは git fsck --lost-found で中身を探せることがあります）。

Q. git reset と git revert はどう使い分けますか？ A. push 前は reset（履歴を書き換える）、push 後は revert（履歴を残して打ち消す）が基本です。

Q. HEAD^ と HEAD~1 の違いは？ A. 通常のコミットでは同じ「1つ前」です。マージコミットでは HEAD^2 が2番目の親、HEAD~2 が2世代前を指します。

Q. 最初のコミットを取り消すには？ A. 親のコミットが無いため、git reset --soft HEAD~1 は fatal: ambiguous argument 'HEAD~1': unknown revision or path not in the working tree. になります。git update-ref -d HEAD を実行すると、コミットが消えてファイルはステージに残りました（git status は No commits yet）。

Q. 間違えて別のブランチにコミットしました。 A. 正しいブランチに移って git cherry-pick <コミットID> でコミットを写し、元のブランチで（push 前なら）git reset --hard HEAD~1 で取り消します。

まとめ

• push 前は git reset（--soft は変更をステージに、--mixed はファイルに残す。--hard は消す）か git commit --amend
• push 後は git revert。マージコミットは git revert -m 1
• revert したマージを取り込み直すには、revert を revert する（Git 2.43 からメッセージは Reapply）
• --force は他の人のコミットを消す。強制 push するなら --force-with-lease --force-if-includes
• 間違えても、コミット済みなら git reflog で戻せる。add だけの内容は git fsck --lost-found、add もしていない変更は戻せない
• add の取り消しは git restore --staged、ファイルの変更を捨てるのは git restore

参考・出典

確認日はいずれも 2026年10月14日です。

• Git 公式マニュアル git-reset：https://git-scm.com/docs/git-reset
• Git 公式マニュアル git-revert：https://git-scm.com/docs/git-revert
• Git 公式マニュアル git-push（--force-with-lease・--force-if-includes）：https://git-scm.com/docs/git-push
• Git 公式マニュアル git-reflog：https://git-scm.com/docs/git-reflog
• Git 公式マニュアル git-gc（gc.reflogExpire・gc.reflogExpireUnreachable）：https://git-scm.com/docs/git-gc
• Git 公式マニュアル git-restore：https://git-scm.com/docs/git-restore
• Git 2.43.0 リリースノート：https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.43.0.adoc
• Git 2.30.0 リリースノート：https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.30.0.adoc
• Git 2.23.0 リリースノート：https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.23.0.adoc
• VS Code Docs「Staging, commits, and undo」：https://code.visualstudio.com/docs/sourcecontrol/staging-commits
• GitHub Docs「About protected branches」：https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。