配布資料 45事例 #05: スカッシュマージで実装済みコードが静かに消えた

エラーは出ません。警告も出ません。コマンドは「成功」と表示されます。 それでも、実装済みのコードが消えていました。

何が起きたか

小さな機能追加の PR——管理画面の情報ページと導線ボタン——をマージしました。

その直後、大規模リファクタリングの PR（71ファイル変更）が同じファイルに触れてマージされ、先の PR で追加したページと導線ボタンのコードが上書きで消失しました。

消えたことに気づいたのは翌日です。 git 履歴から該当コミットを掘り起こして復元しました。

なぜ起きたのか

表面的には、大規模 PR のマージ時に、並行 PR の変更を含まない状態でコンフリクト解決が不完全なままマージされたことです。

構造はスカッシュマージにあります。 ブランチの個別コミット履歴を1コミットに潰すため、(1) コンフリクト解決の漏れが履歴上追いにくく、(2) 並行 PR の変更を「静かに」巻き戻します。

大型リファクタ PR と小型機能 PR の並行という、起きやすい状況が重なりました。

そこから生まれたルール

事故の2日後に禁止事項として明文化しました。

「スカッシュマージ禁止。必ず通常マージ（merge commit）を使う。スカッシュマージはソースコードの欠損事故を引き起こす」

あわせて「PR はテスト完了後すぐマージする（オープン放置禁止）」。 並行期間を短くすること自体が予防になります。

どう機械に守らせたか

マージコマンドを検知する PreToolUse フックが、フロー完了確認とあわせて発動し、案内文で通常マージ形式（--merge）のみを正規手順として提示します。

正直に書いておくと、--squash を直接ブロックする専用の検査は持っていません。 規約とフックの案内、そして AI への常時注入で運用しています。強制の穴として認識しています。

持ち帰るなら

マージ戦略は好みの問題ではなくデータ保全の問題です。

AI に並列で PR を作らせる開発では、履歴が消えるマージ方式のリスクが人間の開発より増幅されます。 「消えたけれど git から復元できた」のは、通常マージの履歴が残っていたからでもあります。

履歴を捨てる操作を既定にしないでください。