【Git】git push 取り消しの手順をわかりやすく解説
はじめに
Gitを使ってソースコードを管理していると、うっかりpushしてはいけない変更をリモートリポジトリに反映してしまうことがあります。
例えば、まだ調整中のコードを誤ってチーム全体に共有してしまったり、社外に公開されるリポジトリにプライベート情報を含めてしまったり。
そのようなとき、早めにpushを取り消す対応をとらないと、余計な混乱やセキュリティ上のリスクが発生するかもしれません。
ここでは、git push 取り消しにフォーカスして、さまざまな状況でどのようにコマンドを使って対処すればよいのかをわかりやすく説明します。
この記事を読むとわかること
- ローカルとリモートの両方で取り消すための基本的な考え方
git revertとgit resetの違いと選び方- コミット履歴を取り消す具体的な手順とコード例
- 実務で考慮すべき注意点やチームメンバーとの連携方法
git pushを取り消す場面はどんなとき？
誤ったpushを取り消す必要があるケースは想像以上に多くあります。
特に初心者の方は「一度pushしたら後戻りはできないのでは？」と不安を感じるかもしれません。
しかし実際には、Gitには履歴をさかのぼったり変更を取り消したりする強力な機能が備わっています。
ここでは、代表的なシチュエーションをいくつか挙げてみましょう。
機密情報を含むファイルをpushしてしまった
例えばAPIキーやパスワードなど、チーム外に知られたくないデータを誤ってpushしてしまうことは意外とよくあります。
この状態を放置すると、セキュリティリスクになりかねません。
速やかに取り消し、かつ必要に応じてそれ以外の箇所で対処することが求められます。
実験的なコードを共有リポジトリにpushしてしまった
個人的に試していたブランチを間違えてpushしてしまい、そのままチーム全体のリポジトリに反映されてしまうケースもあります。
不要なコミットを含んだまま開発を続けると混乱するので、コミットを取り消したり戻したりして履歴を整理したいと考えるでしょう。
タイミングを間違えてpushした
まだレビューが終わっていない、あるいはチーム全員が合意していない段階でpushしてしまうと、作業手順に混乱が生じる恐れがあります。
こうした場合にも、なるべく早めに取り消すことで影響を最小限に抑えたいものです。
git push 取り消しの基本的な考え方
誤ったpushを取り消す方法は大きく分けて2つあります。
1つは履歴に新たな「取り消しコミット」を作成する方法で、もう1つはそもそも誤ったコミットを無かったことにして、リモートを上書きする方法です。
ここからは、初心者の方でも混乱しないよう、少しずつ手順やコマンドの意味を紐解いていきます。
取り消しコミットを追加する方法（git revert）
git revert は、指定したコミットを逆向きに上書きすることで、履歴に「取り消しを行った」という事実がしっかり残る形で処理を行う方法です。
実務で履歴の改ざんが好ましくない場合や、多人数が同じリポジトリを利用している場合によく使われます。
具体的には、やらかしてしまったコミットを打ち消す別のコミットを新たに作成してpushします。
この方法だと、誤ったコミットを直接削除したり書き換えたりはしません。
そのため、誰がどの段階で何をミスしたのかが後からでも確認しやすいという利点があります。
コミットを無かったことにする方法（git reset + push --force）
一方で、コミットを削除または書き換えた上でリモートリポジトリに再度pushする（force push）方法もあります。
これは**git reset --hard** などを使って、ローカルの履歴を一度過去の状態に戻し、その戻った履歴を**git push --force** でリモートに上書きするという手段です。
メリットとしては、不要なコミット履歴が残らないため、履歴がすっきりするという点があります。
ただし、すでに他のメンバーがそのコミットをもとに作業を進めている場合、大きなトラブルを引き起こす可能性があるため注意が必要です。
誤ったコミットを無かったことにする操作を実行すると、他のメンバーのリポジトリとの間で履歴が食い違う恐れがあります。共同作業の場では、あらかじめチームに周知してから実施しましょう。
実務での活用シーン
実際の開発現場では、以下のような観点で「どの方法を使うか」を選ぶことが多いです。
多人数が作業しているメインブランチの場合
チーム全員が使う メインブランチ (mainやmaster) で誤ったpushが発生したら、git revert を使うことを検討するのが一般的です。
それによって「いつ、なぜ、何を取り消したか」が明確に残ります。
後から改変履歴をチェックする機会がある場合、履歴を改ざんしない方法の方が望ましいでしょう。
個人作業のブランチや、影響範囲が限定されている場合
実験的なブランチで、他のメンバーの作業に影響がないようであれば、git reset --hard と git push --force をするケースもあります。
特に一人しか使っていないリポジトリやブランチの場合は、コミット履歴をすっきり整えるために強制的に書き換えることが多いです。
ただし、何らかの事情で履歴を改ざんしたくない場合は慎重に考えましょう。
git revertを使った取り消し手順
ここからは、具体的なコマンド例を交えながら、git revert を使ってpushを取り消す流れを説明します。
例として、最新のコミットを1つだけ取り消したい場合を想定します。
# 現在のブランチがメインブランチであることを確認（例：main） git switch main # 最新のコミットを取り消す git revert HEAD # テキストエディタが開き、コミットメッセージを編集 # 必要に応じてメッセージを修正したら保存して終了 # 変更をpush git push origin main
この操作により、「取り消し内容を適用するコミット」が追加されます。
履歴としては元のコミットも残りますが、結果としてコード状態は取り消し後の状態になります。
過去のコミットを取り消したい場合
もし最新ではなく、少し前のコミットを取り消したい場合は、取り消したいコミットのハッシュ値を確認し、以下のように指定します。
# 取り消したいコミットのハッシュが abc123... などの場合 git revert abc123 git push origin main
こちらも基本的な流れは変わりませんが、複数コミットをまとめて取り消すときは個別に対応するか、オプションを工夫する必要があります。
git reset + push --forceを使った取り消し手順
続いて、コミット自体をなかったことにしてpushを上書きする方法です。
例として、直近1つのコミットを取り消したい場合の流れを示します。
# mainブランチへ移動 git switch main # 最新コミットから1つ前の状態に戻す git reset --hard HEAD~1 # リモートを強制的に上書き git push origin main --force
これで、リモートリポジトリからも先ほどのコミットは完全に消えたかのように見えます。
ただし、他の人がすでにそのコミットをpullしている可能性がある場合は、チームメンバーとの連携を必ず行いましょう。
強制上書きする際の注意点
強制pushは便利ですが、誤って意図しない履歴を削除するなどの事故を起こすリスクもあります。
もし、他のメンバーがその取り消したコミットを参照していた場合、コミットの整合性が崩れてしまうかもしれません。
実務では「誰も参照していないブランチであることを確認する」「メンバーに周知する」などのステップを踏んだ上で慎重に実施するのがポイントです。
よくある疑問
ここまでの解説で、初めてGitを触る方はさらにいくつかの疑問が浮かんだかもしれません。
ここでは、よく挙がる質問とその回答をまとめています。
git revert したのにまた別のミスコミットが見つかった場合
複数のコミットを連続で取り消す必要がある場合は、その都度 git revert していきます。
取り消すごとに新たなコミットが作られるため、履歴は少し長くなるかもしれません。
履歴の長さよりも、誤ったコミットを正しく打ち消すことが優先なので、焦らず1つずつ処理しましょう。
git reset --hard で戻したローカル状態を再度pushしたらファイルが消えた
これは、reset した状態がリモートの最新より後退しているために、リモートの更新がすべて上書きされるケースです。
コミットだけでなく、ファイルそのものが消えてしまったように見えることもあります。
実際にファイルを削除しているわけではありませんが、コミット履歴が巻き戻っているため、該当の変更がリモート上から見えなくなるのです。
どちらを使うか迷ったときの判断基準
初心者のうちは、git revert を優先して使うのがおすすめです。
開発規模が大きくなってくると、ブランチ戦略や開発フローによっては**git reset --hard** + --force を頻繁に使う場面も出てきます。
最終的には、チームのルールやリポジトリの運用方針に沿って選択すると良いでしょう。
取り消し後の実務的な流れ
pushの取り消し作業が完了した後、実務では以下のようなステップを踏むことが多いです。
1. チームメンバーへの連絡
誰かが間違ったコミットをpullしていないか、共有することが大切です。
尤も、誤った情報が社外に公開されるリポジトリであれば、尚更急ぎで報告しましょう。
2. 再度テストを実行
取り消しによって動作が変わっていないか、最低限テストや確認を行うことをおすすめします。
3. 必要に応じて追加作業
もし機密情報をpushしてしまった場合は、コミット履歴の削除だけでなく、キーの再発行などの対策が必要です。
こうしたフォローアップ作業を怠ると、せっかく取り消しができても問題が再燃してしまうかもしれません。
チームで作業するときのコツ
1人で開発しているときは、自分の作業を把握しているので対処もしやすいでしょう。
しかし、チーム開発では、ブランチの状態やコミットの参照状況がメンバーごとに異なる可能性があります。
事前にコミットログを確認する
誤ってpushしたコミットがブランチ内のどこに含まれているのか、git log などでしっかり把握しましょう。
曖昧なままresetやrevertを行うと、必要なコミットまで巻き戻してしまうリスクがあります。
「revert しました」などのコミットメッセージをわかりやすく
単に git revert HEAD を行っただけでは、デフォルトのコミットメッセージになることが多いです。
後から履歴を追ったときに困らないよう、コミットメッセージを自分やチームメンバーが理解しやすい形に編集するのがおすすめです。
巻き戻しは慎重に（特にforce push）
git push --force は強力なコマンドです。
巻き戻したコミットを他の人が既にfetchしている可能性を考慮し、必ず周知した上で実行しましょう。
実務では、誤ってpushした直後に誰もpullしていなければ、被害は最小限で済むことが多いです。
そのため、普段から自分の作業状況をチームと共有しておくと、万が一の際もスムーズに対処できます。
一連の流れを踏まえた具体例
最後に、ある架空の例を示します。
- mainブランチにAPIキーを含むファイルを誤ってpushしてしまった
- チームメンバーはすでに何名かpullしているかもしれない
- 公開リポジトリではあるが、まだ外部の人が気づいていないと想定
この場合、以下のように対処するのが一般的です。
1. チームに誤りを報告
Slackなどで「APIキーを含むコミットを誤ってpushしたので、取り消します」と連絡
2. コミット履歴を戻す or revert するか判断
今回は公開リポジトリかつ複数人がpullしている可能性が高いので、git revert を選択
→ 履歴を改ざんしない形で、取り消しコミットを作成
3. git revert の実行
git revert <誤ったコミットのハッシュ> git push origin main
APIキーを含むファイルが削除されたコミットが追加される
4. キーの再発行など、追加対策
万が一に備えてAPIキーを再発行し、旧キーを無効化
まだインターネット上にキャッシュが残る可能性もあるので、関連情報をチェック
このように、一連の手順を踏むことで、履歴を安全に管理しつつ、誤pushによる問題を最小限に抑えられます。
万一、誤ったコミットが一般公開されている場合は、キーの再発行などの追加対策も検討してください。 取り消し作業だけでは情報漏洩リスクが完全にゼロになるわけではありません。
まとめ
git push 取り消しには、git revert と git reset --hard + push --force の2種類のアプローチがあります。
チーム開発のメインブランチや公開リポジトリのように、履歴を改ざんすべきでない場面では**git revert** を使うと安心です。
一方、個人の実験用ブランチやまだ誰もpullしていないケースでは、強制的にコミットを消してしまう方法も採用されることがあります。
特に、git push --force を使うときはチーム内で周知を徹底することが大事です。
実際に誤ってpushしてしまうと焦ることが多いですが、Gitには履歴をさかのぼる機能が充実しています。
今回紹介したコマンド例を手がかりに、落ち着いて適切な方法を選んでください。
それが「まだ誰もpullしていないならresetで消すべきか？」「大勢が参照しているならrevertにするべきか？」といった場面での判断材料になるでしょう。
もし機密情報が外部に漏れた可能性がある場合は、 取り消し作業だけではなく、後続の対策 (キーの再発行やメンバーへの注意喚起など) を行うことが重要です。
このように、Gitの仕組みを理解しておくと、予想外の事態が起きたときでも素早く対応できます。
4000文字以上