第17回: revertの基本 — 本番で「安全に取り消す」ために履歴を壊さないという考え方

章: 第5章: 変更履歴を実務で整える

実務で本当に怖いのは「間違えた変更」より「取り消し方を間違えること」

開発では、マージした変更をあとから取り消したくなることがあります。

• バグを入れてしまった
• 仕様理解がずれていた
• 本番で問題が出たので戻したい

このとき初心者が混同しやすいのが、reset と revert です。

実務では、共有済みの履歴を安全に取り消したい場面で revert がよく使われます。

理由は、履歴そのものを消すのではなく、「打ち消す変更を新しく追加する」からです。

revert は何をしているのか

たとえば、あるコミットでログイン機能を壊してしまったとします。

revert を使うと、そのコミットをなかったことにするのではなく、その変更を打ち消すための新しいコミット を作ります。

git revert <コミットID>

これにより、履歴は残したまま、安全に「取り消した」という事実も追えるようになります。

なぜ実務で好まれるのか

チーム開発や本番運用では、すでに共有された履歴を書き換えるのはリスクがあります。

そこで revert を使えば、

• 履歴の整合性を壊しにくい
• 何を取り消したかが明確に残る
• 他のメンバーとの認識ズレを起こしにくい

という利点があります。

つまり revert は、「なかったことにする」より「安全に打ち消す」を重視した操作です。

reset とどう違うか

個人のローカル作業なら reset が便利なこともありますが、共有済み変更の取り消しでは revert の方が実務向きです。

どんな場面で使うか

• マージ後に不具合が見つかったとき
• 本番反映した変更を一時的に戻したいとき
• 共有済み履歴を壊さずに修正したいとき

特に本番障害の初動では、「原因を完全に直す」より先に、「問題のある変更を安全に戻す」判断が重要になることがあります。

実務で意識したいこと

• 何を取り消すのかを正確に確認する
• 1コミットだけでよいのか、関連変更も必要かを考える
• revert したあとにテストや確認を行う
• 取り消した事実をチームへ共有する

「戻せたから終わり」ではなく、「安全に戻して状況を安定させる」までが実務です。

チェックポイント: 実務での revert は「履歴を消す」操作ではなく、「共有済み変更を安全に打ち消す」操作です。

まとめ & 次のステップ

• revert は変更を打ち消す新しいコミットを作る
• 共有済み履歴を壊しにくいため、実務でよく使われる
• reset は位置を戻す、revert は安全に打ち消すという違いがある
• 本番やチーム開発では履歴の整合性が重要
• 取り消し後の確認と共有まで含めて運用することが大切

次回は cherry-pick を扱います。 別ブランチの変更を必要なものだけ選んで持ってくる場面は、実務では意外とよく出ます。