こんにちは！iimonでフロントエンジニアをしている「奥島」です！
記事を書くきっかけ
今回は、私自身が Git の操作で実際に経験したトラブルをまとめました。 同じようにブランチ操作や Revert で悩んでいる方の参考になれば嬉しいです。
何が起きたのか
作業中、develop にマージしたはずの変更が Revert コミットによって打ち消されてしまう という事態が発生しました。
原因をたどると、 似た名前のブランチを誤って操作してしまった
Revert の仕組みを正しく理解していなかった という2点が重なって起きたものでした。
原因の整理
直接原因
Revert によって、取り込んだ変更が打ち消されたこと。
根本原因
ブランチの役割を誤認し、かつ「Revert は取り消しを記録する操作」であることを理解していなかったため、本来不要な Revert を develop に取り込んでしまったこと。
どうしてそうなったのか
対象ブランチの関係性
サイト追加用
- feature/add-fukuoka （エリア追加工数削減の調査用として作成 Fサイトの親ブランチ）
- feature/add-F (サイト追加対応ブランチ（Aさんが作業していたブランチ）)
- feature/add-fukuoka （エリア追加工数削減の調査用として作成 Fサイトの親ブランチ）
福岡エリア沿線追加用
- feature/fukuoka-add-area （エリア追加の親ブランチ）
- feature/add-area-fukuoka-A (沿線追加サイト 作業用ブランチ（Bさんが作業していたブランチ）)
- feature/fukuoka-add-area （エリア追加の親ブランチ）
発生手順
今回のトラブルは、複数のブランチを操作する中で発生しました。 手順を整理すると次の通りです。
feature/add-fukuokaから福岡エリア追加とFのサイト追加を並行で行うこととなった
エリア追加タスク側でfeature/add-fukuokaから追加する形だとブランチに存在する沿線データと新しく取得する必要のある沿線データの差分比較するのが手間だったので作り直した方が早いと判断しfeature/fukuoka-add-areaを作成した
feature/fukuoka-add-areaからAの沿線データ追加用のブランチfeature/add-area-fukuoka-Aを作成
feature/add-area-fukuoka-Aの作業が完了したので親ブランチにマージしようとした時本来であればfeature/fukuoka-add-areaにマージしなくてはいけなかったが誤ってfeature/add-fukuokaにマージした
想定していないブランチであるfeature/add-fukuokaにマージしたためfeature/add-area-fukuoka-Aの変更をrevertした
6.Fサイト追加のブランチはfeature/add-fukuokaからブランチfeature/add-Fを作成 した
7.Fサイト追加のタスクで沿線データが必要になったタイミングでfeature/fukuoka-add-areaをfeature/add-fukuokaにマージ（この時に5のリバートコミットが含まれていた）
8.feature/add-fukuokaをfeature/add-Fにマージした
結果 developはfeature/fukuoka-add-areaのA沿線データのコミットよりfeature/add-Fのリバートコミットの方が履歴的に最新なのでリバートされた状態となった
もし途中で気づけていたらできた対処法
今回私は Revert が不要だと気づかないまま作業を進めてしまったため、最終的に develop 上で意図せず変更が打ち消されてしまいました。 もしこの時点で「Revert は不要だった」と気づけていたら、以下のような安全な対応ができました。
Revert の Revert を実行する
Revert は「取り消した記録」を残す操作なので、その Revert 自体をさらに Revert すれば元の変更を復活できます。 この操作により、Revert によって打ち消された変更を安全かつ確実に再度適用できます。
実体験から学んだ再発防止策
ブランチの役割を正確に把握する
- 類似ブランチが並行して存在していたため、操作する前に「今触っているブランチは何のためか」を頭で整理してから進める
Revert の挙動を理解する
Revert は「なかったことにする」わけではなく「取り消しを記録する操作」であることを十分に理解していなかった
結果として、feature/fukuoka-add-area の内容が develop に取り込まれていたにも関わらず、feature/add-fukuoka の Revert によって意図せず打ち消されてしまった
Revert を行う際は、どの履歴にどう影響するかを事前に確認することが重要
操作前の確認を習慣化する
冷静に操作できていたとはいえ、確認不足がトラブルを招いた
マージや Revert の前に「どのブランチを操作しているか」履歴にどう影響するか」を必ず確認する習慣をつける
チームでの共有強化
「このブランチは調査用」など、意図を Slack で共有する。
マージや Revert を行う前に、必ず他メンバーに確認する。
まとめ
今回のトラブルは、
似た名前のブランチを混同したこと
Revert の仕組みを正しく理解していなかったこと
運用ルールが曖昧だったこと
が重なって起きました。
Git の操作は一見シンプルですが、運用を誤ると履歴を壊したり、成果を打ち消したりするリスクがあります。
今回の失敗から学んだのは、
ブランチ運用ルールを明確にする
Revert の扱いを慎重にする
チームでの共有を徹底する
ということです。
今後は「冷静に、正しく、共有しながら」Git 操作を進め、同じ失敗を繰り返さないようにしていきたいと思います。
おわりに
最後になりますが、弊社ではエンジニアを募集しています！
この記事を読んで少しでも興味を持ってくださった方は、ぜひカジュアル面談でお話ししましょう！
iimon採用サイト / Wantedly / Green
