Gitの次期メジャーリリースは、通常のバージョン更新ではなく、長年にわたる複数の設計方針からの組織的な転換として位置づけられています。LWNは2026年9月18日のレポートで、予定されているGit 2.56のリリース後にGit 3.0が検討されており、互換性に影響を及ぼす変更はメジャーリリースへ移される見込みだと伝えています。同レポートの更新情報では、合意された工程として、2026年12月にGit 2.98、2027年4月に長期サポート版となるGit 2.99、そして同じ時期にGit 3.0をリリースする方針が示されています。この工程を報じているのはLWNであり、提示されたGit公式ドキュメントが独自に確認しているわけではありません。
この記事はGitのリポジトリオブジェクト、参照領域の保管形式、ビルド要件における主要な変更を扱っており、公式プロジェクトロゴはGitを直接的に示す識別子です。 出典・クレジット：git-scm.com。
最も明確な変更は、GitリポジトリでSHA-1からSHA-256へ移行する案です。Gitはハッシュを使ってファイル、ディレクトリツリー、コミットを識別し、履歴の連鎖を検証します。LWNによると、SHA-1は安全性が弱いと考えられており、理論上、攻撃が成功すればリポジトリの履歴を信頼しにくくなる可能性があります。Gitには既知のSHA-1攻撃に対する防御機構がすでに組み込まれており、LWNは実験段階ではないSHA-256サポートが2023年のGit 2.42から存在していると報じています。これらの記述は、移行のセキュリティ上の根拠と実装の経緯を示すものであり、既存のSHA-1リポジトリが現在実際に侵害されていることを示すものではありません。
したがって、実務上の移行課題は、SHA-256の方が強力かどうかだけではありません。プロジェクトを取り巻くリポジトリ、ホスティングサービス、各種ツールが移行期間中に連携できるかが問われます。LWNはGitLabとForgejoがすでにSHA-256に対応している一方、提示された資料だけではGitHubの対応状況は明確でないと報じています。また、この移行に取り組む貢献者でありGitHub社員でもあるbrian m. carlson氏が、この件に関する発表が近づいていると述べ、次期リリースをGit 3.0にすることが適切かもしれないと示唆したとも伝えています。これは関係者個人の意見であり、GitHub製品に関する公式発表でも、互換性が証明された根拠でもありません。
もう一つの主要な保管形式の変更案が、参照領域をreftableへ移行することです。現在のGitは、ブランチやタグなどの参照を`.git/refs/`配下のファイルとして保存し、一部を統合するために`packed-refs`の仕組みも利用しています。LWNはGitのreftableドキュメントを引用し、Androidリポジトリには80万を超える参照があり、参照の多いリポジトリでは検索に大きなコストがかかる可能性があると説明しています。reftableは参照をバイナリ形式で保存し、占有領域を減らしてより高速なアクセスを可能にする仕組みです。Git 2.45ではreftableを保管領域としてリポジトリを作成できるようになりましたが、提示されたドキュメントから、reftableがすでに標準設定になっていることを確認することはできません。
想定される利点は、大半のユーザーには直接見えない運用面での効率化です。大規模リポジトリでは、参照をより効率的に処理できる可能性があります。一方、想定されるリスクは周辺領域にあり、特にGit自体を使わずリポジトリを読み書きする別のプログラムに影響が出ます。LWNはlibgit2を互換性上の懸念候補として挙げ、その後、Patrick Steinhardt氏によると、libgit2が8月にreftable対応を追加し、SHA-256対応を標準で有効化したと報じています。これは開発状況に関する attributable な更新情報ではなく、明確に本人へ帰属された開発報告です。libgit2の準備が進んでいたことは裏付けられますが、libgit2を組み込むすべてのアプリケーションに必要な対応が反映済みであるまでは確認できません。
3つ目の変更案は、GitのビルドにRustを必須化することです。LWNによると、Gitには試行段階のRust対応がありますが、動作可能なRustコンパイラの利用を必須にすることには慎重な姿勢を示してきました。この案どおりに公開されれば、適切なRust開発環境を利用できないプラットフォームでは、新しいGitバージョンをビルドできなくなります。提示された資料は、どのプラットフォームが影響を受けるのか、必要なコンパイラはどのバージョンなのか、下流のディストリビューションが代替手段を提供するのかを特定していません。したがって、根拠が裏付けるのはこの案の存在と影響の可能性であり、移植性に関する包括的な評価ではありません。
この議論から、リポジトリのオブジェクト形式を変更することと、通常のコミット履歴を書き換えることは区別して考える必要があります。提示された資料だけでは、すべてのSHA-1リポジトリで強制プッシュが必要になるのか、ホスティング事業者が移行済みリポジトリをどのように公開するのか、形式が異なるサブモジュールがどのように動作するのかには回答できません。こうした疑問は、個人的な経験談から推測して答えるのではなく、未解決のままにしておくべきです。一方、SHA-256対応がすでに存在すること、メジャーバージョンの計画が互換性対応と結びついていること、そしてコードホスティングサービスと関連ツールの準備状況が中心的な制約になっていることは、根拠から確認できます。
重要なリポジトリを管理する読者にとって、当面の課題は、Git 3.0をインストールしても問題なく透過的に移行できるものと想定せず、依存関係を事前に把握することです。対象には、リポジトリのホスティング事業者、CIシステム、バックアップ・アーカイブ用ツール、コードレビュー用ソフトウェア、IDE統合、libgit2などのライブラリが含まれます。また、SHA-256やreftableをローカルで試すことと、共同作業者やサービスがリポジトリデータを交換する方法を変える組織的な移行を区別する必要があります。提示された資料には普遍的な移行手順が示されていないため、導入計画は関連する事業者とツールのドキュメントが整備されるまで待つべきです。
最も重要な留意点は時期です。LWNの更新情報は具体的なリリース工程を示していますが、この資料一式には、それを確認できる独立したリリース発表やGitプロジェクトの一次資料が含まれていません。同様に、LWNの目視できる署名から、情報源の正確な公開日が2026年9月18日であることは明確です。一方、資料一式の生成日はそれより後であり、記事の公開日とみなすべきではありません。最も慎重な解釈は、Git 3.0が大規模な準備作業を伴う計画された方向性であり、互換性と工程がすで確定した完了済みの移行ではないという点です。