「やばい!間違ったコミットをプッシュしてしまった!」 「APIキーを含んだファイルをGitHubに上げてしまった…」 「コミットメッセージを間違えたまま、もうプッシュ済み…」
リモートリポジトリにプッシュしてしまったコミットの取り消し、これはGitを使う上で最も慎重に扱うべき操作の一つです。なぜなら、他の開発者に影響を与える可能性があるから。
でも大丈夫。この記事では、安全な方法から最終手段まで、状況に応じた対処法をすべて解説します。チーム開発でも個人開発でも、適切な方法を選べるようになりますよ。
ただし、一度インターネットに公開された情報は完全には消せないことも覚えておいてください。特にセキュリティに関わる情報は、この記事の方法で履歴から削除しても、別途対策が必要です。
まず理解すべき:ローカルとリモートの違い

Gitの3つの領域
作業の流れ:
作業ディレクトリ → ステージング → ローカルリポジトリ → リモートリポジトリ
(add) (commit) (push)
なぜリモートの取り消しは難しい?
ローカルの場合:
- 自分だけの環境
- 自由に履歴を変更できる
- 他人への影響なし
リモートの場合:
- 他の開発者と共有
- すでに他の人がpullしているかも
- 履歴の変更は大きな影響
重要な原則: 「公開された履歴は書き換えない」が基本。でも、状況によっては必要な場合も。
状況別:最適な対処法の選び方
診断チャート
あなたの状況はどれ?
Q1: 他の開発者がすでにpullした可能性は?
- Yes → 方法1(revert)一択
- No → Q2へ
Q2: 取り消したいコミットは直前の1つだけ?
- Yes → 方法2(reset + force push)
- No → Q3へ
Q3: 履歴を完全に消したい?
- Yes → 方法3(rebase -i + force push)
- No → 方法1(revert)
Q4: セキュリティに関わる情報が含まれている?
- Yes → 方法4(特別な対処)+ 追加のセキュリティ対策
方法1:git revert【最も安全】
revertとは
新しいコミットで打ち消す方法
- 履歴は残る
- 安全で推奨される方法
- チーム開発でも問題なし
基本的な使い方
直前のコミットを取り消す:
# 1. 取り消したいコミットのハッシュを確認
git log --oneline
# 2. revertを実行
git revert HEAD
# 3. リモートにプッシュ
git push origin main
特定のコミットを取り消す:
# コミットハッシュを指定
git revert abc1234
# 複数のコミットを取り消す
git revert abc1234..def5678
# プッシュ
git push origin main
メリット・デメリット
メリット:
- ✅ 履歴が残るので追跡可能
- ✅ 他の開発者への影響最小
- ✅ いつでも元に戻せる
- ✅ コンフリクトのリスク低
デメリット:
- ❌ 履歴が汚れる(取り消しの記録が残る)
- ❌ 機密情報は履歴に残ったまま
- ❌ コミット数が増える
実例:間違った機能を追加した場合
# 状況:feature-xを間違って実装してプッシュ済み
git log --oneline
# abc1234 feat: add feature-x (これを取り消したい)
# def5678 fix: bug fix
# ghi9012 docs: update README
# revertで取り消し
git revert abc1234
# エディタが開く → コミットメッセージを編集
# デフォルト: "Revert "feat: add feature-x""
# プッシュ
git push origin main
# 結果の履歴
# jkl3456 Revert "feat: add feature-x" ← 新しいコミット
# abc1234 feat: add feature-x ← 履歴は残る
# def5678 fix: bug fix
方法2:git reset + force push【直前のコミット用】
resetとforce pushの組み合わせ
履歴を巻き戻す方法
- 指定した状態まで戻る
- force pushで強制的に上書き
- ⚠️ 他の開発者に影響大
手順
直前のコミットを完全に取り消す:
# 1. 直前のコミットを取り消し(ファイルは残る)
git reset --soft HEAD~1
# または、ファイルの変更も取り消す
git reset --hard HEAD~1
# 2. 強制プッシュ
git push --force origin main
# または、より安全な
git push --force-with-lease origin main
resetの3つのモード
–soft:
git reset --soft HEAD~1
# コミットだけ取り消し
# 変更はステージングに残る
# ファイルの内容はそのまま
–mixed(デフォルト):
git reset HEAD~1
# コミットとステージングを取り消し
# 変更は作業ディレクトリに残る
–hard:
git reset --hard HEAD~1
# すべて取り消し
# ファイルも元の状態に戻る
# ⚠️ 作業内容が完全に消える
force pushの注意点
通常のforce push:
git push --force origin main
# 問答無用で上書き
# 他の人のコミットも消える可能性
より安全なforce-with-lease:
git push --force-with-lease origin main
# リモートが更新されていたら失敗
# 他の人の作業を守る
実例:パスワードを含むコミット
# 状況:config.jsにパスワードを書いてプッシュしてしまった
git log --oneline
# abc1234 feat: add config (パスワード入り) ← これを消したい
# def5678 fix: bug fix
# ローカルで取り消し
git reset --hard HEAD~1
# 強制プッシュ
git push --force-with-lease origin main
# ⚠️ ただし、GitHubには履歴が残る可能性
# パスワードは必ず変更すること!
方法3:git rebase -i【複数コミットの編集】

interactive rebaseとは
履歴を自由に編集する方法
- 複数のコミットを整理
- コミットの順序変更も可能
- 究極の履歴改変ツール
基本的な使い方
# 1. 過去3つのコミットを編集
git rebase -i HEAD~3
# 2. エディタが開く
pick abc1234 commit 1
pick def5678 commit 2 ← これを削除したい
pick ghi9012 commit 3
# 3. 削除したいコミットの行を削除、または'drop'に変更
pick abc1234 commit 1
drop def5678 commit 2
pick ghi9012 commit 3
# 4. 保存して終了
# 5. force push
git push --force-with-lease origin main
rebaseのコマンド一覧
エディタで使えるコマンド:
コマンド | 説明 | 用途 |
---|---|---|
pick | コミットを使用 | そのまま残す |
reword | コミットメッセージを編集 | メッセージだけ変更 |
edit | コミットを修正 | 内容を変更 |
squash | 前のコミットに統合 | コミットをまとめる |
fixup | squashと同じだがメッセージ破棄 | きれいにまとめる |
drop | コミットを削除 | 完全に消す |
実例:複数の間違いを修正
# 状況:3つのコミットのうち2つを修正したい
git log --oneline
# abc1234 feat: feature A
# def5678 typo: fix typo ← タイポがある
# ghi9012 WIP: temporary ← これは消したい
# jkl3456 fix: bug fix
# interactive rebase開始
git rebase -i HEAD~4
# エディタで編集
pick abc1234 feat: feature A
reword def5678 typo: fix typo # メッセージ修正
drop ghi9012 WIP: temporary # 削除
pick jkl3456 fix: bug fix
# 保存後、rewordのコミットメッセージを編集
# force push
git push --force-with-lease origin main
方法4:セキュリティ情報が漏れた場合の特別対処
緊急対応フロー
1. 即座に無効化
# 例:AWSの場合
# 1. AWS ConsoleでAccess Keyを無効化
# 2. 新しいキーを生成
# 3. アプリケーションを更新
2. 履歴から完全削除
# BFG Repo-Cleanerを使用(推奨)
# 1. BFGをダウンロード
java -jar bfg.jar --delete-files config.json repo.git
# 2. 履歴をクリーンアップ
cd repo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
# 3. force push
git push --force-with-lease origin main
git filter-branchを使った方法
# ファイルを履歴から完全削除
git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch path/to/sensitive-file" \
--prune-empty --tag-name-filter cat -- --all
# リモートにforce push
git push --force --all origin
git push --force --tags origin
GitHub の場合の追加対策
- GitHub Support に連絡
- キャッシュからの削除依頼
- 履歴の完全削除
- Secret Scanning の確認
- Settings → Security → Secret scanning
- アラートの確認
- リポジトリの可視性変更
- 一時的にPrivateに変更
- 対処後にPublicに戻す
チーム開発での注意事項
force push前のチェックリスト
必ず確認:
- [ ] チームメンバーに通知した
- [ ] 他の人の作業がないことを確認
- [ ] バックアップブランチを作成
- [ ] –force-with-leaseを使用
- [ ] プルリクエストへの影響を確認
チームへの通知テンプレート
## Git履歴の修正について
@team
以下の理由により、mainブランチの履歴を修正します:
- 理由:[具体的な理由]
- 影響範囲:[コミットハッシュ]
- 作業予定時刻:[時刻]
### 対応のお願い
1. 作業中の変更をコミットまたはstash
2. 修正完了後、以下を実行:
git fetch origin git reset –hard origin/main
ご迷惑をおかけしますが、よろしくお願いします。
より安全な代替案
別ブランチで修正:
# 1. 新しいブランチを作成
git checkout -b main-fixed
# 2. 修正作業
git rebase -i HEAD~10
# 3. プルリクエスト作成
# 4. レビュー後、mainを置き換え
トラブルシューティング

force pushが拒否される
エラー: remote: error: refusing to update checked out branch
解決法:
# 1. 保護設定を確認
# GitHubの場合:Settings → Branches → Branch protection rules
# 2. 一時的に保護を解除(管理者権限必要)
# 3. force push実行
# 4. 保護を再度有効化
コンフリクトが発生
# rebase中のコンフリクト解決
# 1. コンフリクトを手動解決
git status # コンフリクトファイルを確認
# ファイルを編集
# 2. 解決したらadd
git add .
# 3. rebase続行
git rebase --continue
# または、中止
git rebase --abort
間違えてforce pushしてしまった
他の人のコミットを消してしまった場合:
# 1. reflogで履歴を確認
git reflog
# 2. 消える前の状態を特定
# abc1234 HEAD@{1}: commit: other person's commit
# 3. その状態に戻す
git reset --hard HEAD@{1}
# 4. 再度force push
git push --force origin main
ベストプラクティス
予防策
1. プッシュ前の確認習慣
# プッシュ前に必ず実行
git log --oneline -5 # 直近5件確認
git diff origin/main # 差分確認
git status # 状態確認
2. pre-pushフックの設定
# .git/hooks/pre-push
#!/bin/sh
# 機密情報のチェック
if git diff HEAD origin/main | grep -E "(password|api_key|secret)"; then
echo "機密情報が含まれている可能性があります!"
exit 1
fi
3. .gitignoreの徹底
# 機密情報
.env
config/secrets.yml
*.key
*.pem
# 個人設定
.vscode/
.idea/
プロジェクトルール例
## Git履歴変更ルール
1. **個人ブランチ**:自由に履歴変更OK
2. **featureブランチ**:チームに確認後OK
3. **developブランチ**:原則revertのみ
4. **mainブランチ**:絶対にrevertのみ
## force pushする場合
- 必ずチームに通知
- --force-with-leaseを使用
- バックアップブランチを作成
よくある質問
Q1:GitHubで削除してもコミットが見える
A: GitHubは削除されたコミットをキャッシュしています:
- URLを直接知っていればアクセス可能
- GitHub Supportに完全削除を依頼
- センシティブな情報は必ず無効化
Q2:force pushとforce-with-leaseの違いは?
A:
- –force:問答無用で上書き
- –force-with-lease:リモートが更新されていたら中止
- チーム開発では必ず–force-with-leaseを使用
Q3:大量のコミットを取り消したい
A:
# 特定の地点まで戻る
git reset --hard <commit-hash>
git push --force-with-lease origin main
# または、新しいブランチとして作り直し
git checkout -b main-new <commit-hash>
git push origin main-new
# PRで置き換え
Q4:取り消したコミットを復活させたい
A:
# reflogで探す
git reflog
# abc1234 HEAD@{5}: commit: deleted commit
# cherry-pickで復活
git cherry-pick abc1234
まとめ
リモートにプッシュ済みのコミット取り消しは、慎重に行うべき操作です。
状況別の推奨方法:
🟢 安全第一なら → git revert
- 履歴は残るが確実
- チーム開発の基本
🟡 個人開発なら → reset + force push
- きれいな履歴を保てる
- 自己責任で
🔴 機密情報漏洩なら → 完全削除 + 情報の無効化
- BFG Repo-Cleaner使用
- 必ず鍵やパスワードを変更
golden rule(黄金律): 「一度公開した履歴は書き換えない」
でも、ミスは誰にでもあります。この記事の方法を使えば、適切に対処できます。
最も重要なのは予防。プッシュ前の確認を習慣化し、.gitignoreを適切に設定し、チームでルールを共有しましょう。
Git は強力なツールです。正しく使えば、どんなミスもリカバリーできます!
コメント