GitHubで前の状態に戻したい時の基本
GitHubで戻したいと思った時は、すぐ強い操作へ進まず、まず何を戻したいのかを分けます。ファイル単位なのか、commit単位なのか、PR単位なのか、本番に反映済みなのかで確認順が変わります。
このページでわかること
- 戻したい対象をファイル、commit、PR、本番影響に分ける
- 履歴とdiffを見て、何が入ったか確認する
- Secretsや個人情報が絡む場合は通常の戻し方だけで終わらせない
まず確認すること
- どのrepo、branch、commit、PRの話か確認する
- push済みか、merge済みか、本番反映済みかを見る
- 分からない時は止まって相談できる状態にする
やってはいけないこと
- 履歴を書き換える操作を軽く扱う
- 戻せば必ず元通りになると断定する
- Secrets事故をページ差し戻しだけで扱う
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
公式情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。
戻し方は2種類あり、選び方が決まっている
「前の状態に戻す」には性質の違う2つの方法があり、どこまで公開されているかで選び方が決まります。
| 打ち消して戻す | 履歴ごと消して戻す | |
|---|---|---|
| やること | 変更を取り消す新しい記録を足す | 過去の記録自体を無かったことにする |
| 履歴 | 戻した経緯も残る | 消える |
| 使える場面 | すでに共有・公開したもの | まだ手元だけのもの |
判断は単純で、他の人が見られる状態になっているなら、必ず打ち消す方を選びます。履歴を書き換えると、同じものを使っている人の手元と食い違い、そちらでも問題が起きます。1人で使っていて、まだ手元にしかない変更なら、消す方でも構いません。
どこまで戻すかを先に決める
戻す作業で失敗するのは、方法よりも戻す範囲を決めずに始めることが原因です。「とりあえず前に戻す」と、直したかった1点以外の作業まで消えます。
順番はこうです。まず問題のある変更を特定します。次に、その変更だけを打ち消せるかを見ます。多くの場合、1つの変更だけを狙って戻せます。全体を過去の時点に巻き戻す必要があるのは、複数の変更が絡んで切り分けられない時だけです。
作業前に必ず今の状態の控えを取るのも忘れないでください。戻した結果が想定と違った時に、少なくとも元の場所へは帰れます。