force pushは無意味？mainブランチすら11%履歴改変も残る漏洩リスク
公開日
git commit --amendやgit rebase -iといったコマンドは、Gitのコミット履歴をきれいに整える上で非常に強力なツールです。しかし、これらの「履歴改変」機能は、特にチームで共有している公開ブランチに対して使用すると、他の開発者の作業を混乱させる可能性があるため、一般的には非推奨とされています。では、実際の公開リポジトリでは、この履歴改変はどの程度、そして、どのような目的で行われているのでしょうか。
本記事では、バージョン管理システム（VCS）における履歴改変の実態を初めて大規模に調査した学術論文「Altered Histories in Version Control System Repositories: Evidence from the Trenches」の内容に基づき、その興味深い結果と、開発者が知っておくべき潜在的なリスクについて詳しく解説していきます。
調査概要：1億1100万の公開リポジトリを分析
この調査は、あらゆるソフトウェアのソースコードを保存する普遍的なアーカイブであるSoftware Heritageが収集した、1億1100万件もの公開Gitリポジトリの膨大なデータセットを分析対象としています。研究チームは、異なる時点でのリポジトリの状態（スナップショット）を比較することで、過去に存在したコミットが後のスナップショットから消えているケースを「履歴改変」として検出しました。
結果1：履歴改変の発生頻度 - 100リポジトリに約1つの割合
調査の結果、分析対象となったリポジトリのうち、122万件のリポジトリで履歴改変の痕跡が確認されました。 これは、全体の約1.10% にあたります。
この割合は一見すると小さいように思えるかもしれません。しかし、絶対数で見れば100万を超えるリポジトリが、その歴史の中で何らかの改変を受けていることを意味します。これは、履歴改変が決して稀な例外ではなく、多くの開発現場で起こりうる、無視できない現象であることを示唆しています。
結果2：履歴改変が起きやすい「場所」
では、履歴改変はどのような場所で、より頻繁に発生するのでしょうか。調査では「ブランチの種類」と「リポジトリの人気度」という2つの観点から分析が行われました。
pull requestブランチが最多、しかしmainブランチも1割超え
図表1は、履歴改変が検出されたブランチの分布を示しています。予想通り、マージ前に履歴を整えることが多い 「pull request」関連のブランチが37.57%と最も多くなりました。これは、コミットを一つにまとめたり（squash）、修正を加えたりする一般的な開発慣行を反映した結果と言えるでしょう。
しかし、注目すべきは次に続くブランチです。プロジェクトの最も安定的で公式な歴史であるべき 「main」ブランチ（masterブランチも含む）が11.39%で2番目に多くなっています。本来、一度プッシュされたら変更されるべきではない主要ブランチの履歴がこれほどの頻度で改変されているという事実は、下流の利用者に混乱を招き、リポジトリの信頼性を損なう可能性があることを示しています。
図表1 履歴改変の影響を最も受けたブランチの分布（0.1%以上）
人気リポジトリほど発生率が上昇する傾向
次に、リポジトリの人気度と履歴改変の関係性を見てみましょう。一般的に、多くの開発者が利用する人気リポジトリほど、安定性を重視して履歴改変は少なくなる、と考えるかもしれません。しかし、調査結果は意外な傾向を示しました。
図表2は、リポジトリのGitHubスター数ごとに、履歴改変を経験したリポジトリの割合を示したものです。スター数が0〜1の最も人気のないリポジトリ群では、改変率はわずか0.3%でした。しかし、リポジトリの人気が高まるにつれて改変率も上昇し、スター数が100以上のリポジトリでは3.0%を超えることが明らかになりました。成熟した人気リポジトリでさえも、決して少なくない頻度で履歴改変が行われているのです。
図表2 リポジトリのスター数範囲ごとの履歴改変があったリポジトリの割合
結果3：何が、どのように変更されているのか？
履歴改変によって、コミットの何が変更されているのでしょうか。調査では、改変内容を大きく「メタデータのみの変更」と「ファイルやディレクトリの変更」に分類しています。
約8割はファイル・ディレクトリの変更
図表3が示すように、履歴改変の大部分はファイルやディレクトリのコンテンツに関わるものでした。特に、少なくとも1つのファイルが変更されたケース（File Modified）が6割以上を占めています。ファイルやディレクトリの変更を伴う改変全体（File Modified, File Removed, Content Split）では、76.8% に達しました。一方で、コミットメッセージやタイムスタンプといったメタデータのみが変更されたケースは13.3%に留まりました。
図表3 履歴改変のカテゴリ別分布
よく変更されるファイルは設定ファイルやドキュメント
さらに、変更されたファイルを詳しく見ると、default.nix、package.json、Makefile、pom.xmlといった、ビルドシステムやパッケージマネージャーの設定ファイルが上位を占めていました。これは、依存関係の更新やビルド設定の変更が、履歴改変の主な動機の一つであることを示唆しています。また、README.mdやCHANGELOG.mdといったドキュメントファイルも頻繁に変更されており、ドキュメントの改善も履歴改変の一般的な理由であることが伺えます。
結果4：履歴が改変される2つの主な理由
この調査では、具体的な改変パターンを深掘りするために2つのケーススタディも実施されました。これらは、履歴改変が持つリスクをより明確に示しています。
理由1：漏洩した「秘密情報」の削除
開発者が誤って秘密鍵やパスワード、APIトークンなどの機密情報をリポジトリにコミットしてしまうことがあります。このような場合に、その情報を履歴から完全に消し去る目的で履歴改変が使われることがあります。調査では、秘密鍵によく使われるファイル名などを含むコミットが、履歴改変によって削除されるケースが多数特定されました。
しかし、重要なのは、たとえリポジトリの現在の履歴から削除されたとしても、Software Heritageのようなアーカイブサービスや、誰かがフォークしたリポジトリには改変前の履歴が残っている可能性があるということです。したがって、履歴改変による秘密情報の削除は根本的な解決策にはならず、漏洩したキーやトークンは速やかに無効化する必要があります。
理由2：ライセンスの遡及的な変更
もう一つの興味深いケースは、ライセンスファイルの変更です。オープンソースプロジェクトにおいて、ライセンスは非常に重要な要素ですが、このライセンスファイルが履歴改変によって遡及的に変更される事例が確認されました。例えば、あるバージョンではMITライセンスだったものが、後の履歴改変によってGPLライセンスに変更される、といった事態が起こりえます。
オープンソースライセンスの多くは一度許諾されると取り消せないため、このような遡及的な変更は、過去のバージョンを利用したいユーザーの権利を曖昧にし、法的な混乱や不安定さを生む深刻なリスクをはらんでいます。
まとめ：便利さとリスクの狭間で開発者が知っておくべきこと
今回の1億リポジトリを超える大規模調査は、Gitの履歴改変に関する貴重な実態を明らかにしました。
- 履歴改変は約100リポジトリに1つの割合で発生しており、決して他人事ではありません。
pull requestでの利用が主ですが、安定しているべきmainブランチでも1割以上発生しています。- 人気リポジトリほど発生率が高いという意外な相関関係があります。
- 主な目的は、秘密情報の削除やライセンスの変更といった、一見正当に見える理由ですが、これらは深刻なセキュリティリスクや法的リスクを内包しています。
履歴改変は、開発履歴をクリーンに保つための便利な機能です。しかしその一方で、特に共有されているブランチでの安易な使用は、下流の利用者に予期せぬ影響を与え、ビルドの再現性を損ない、さらには悪意あるコードの混入を隠蔽するサプライチェーン攻撃の温床となる可能性も秘めています。
開発者は、履歴改変がもたらす便利さだけでなく、その裏にあるリスクを正しく認識し、特にチームやコミュニティに影響を与える場面では、その実行について慎重に判断することが求められます。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: