Git 2.56 および 3.0 への展望

LWN.net へようこそ このサブスクリプション限定コンテンツは、LWN の購読者によって提供されました。何千人もの購読者が、Linux およびフリーソフトウェアコミュニティからの最高のニュースのために LWN に依存しています。この記事を楽しんでいただけたなら、LWN の購読をご検討ください。LWN.net をご覧いただきありがとうございます！ Jonathan Corbet 著 2026年9月18日 Git ソースコード管理システムは、世界中の開発プロセスの中心にあり、特に非互換な変更は関係する開発者にとって大きな関心事です。9月末頃にリリースが予想される Git 2.56 は、現在リリース候補版として利用可能です。これはそれほど劇的なリリースではありませんが、それに続く、長らく待望されているかもしれない Git 3.0 は、そうなる可能性があります。Git 2.56 の内容 Git 2.56 リリースには 700 以上の非マージコミットが含まれており、多くの改善をもたらしますが、ほとんどのユーザーにとって Git 体験を根本的に変えるものではありません。その点でいくつかの可能性を秘めている機能は、（まだ実験的な）git history ツールボックスへの drop サブコマンドの追加です：$ git history drop commit-id このコマンドは、指定されたコミットを現在のブランチの履歴から削除し、その後に加えられたすべてのコミットをリプレイします。これは、問題のあるコミットを削除する簡単な方法を提供します。残念ながら、履歴にマージコミットが含まれている場合は、まだ動作を拒否するため、多くの（あるいはほとんどの）リポジトリでは使用できません。git status コマンドは現在、追跡しているブランチに遅れているブランチを更新するために git pull コマンドを提案するようになります。しかし、リモート追跡ブランチに（フェッチされていない）遅れがある場合でも、ブランチが「最新」であると表示し続けます。git refs コマンドは、低レベルで参照を操作するために存在します。2.56 では、いくつかの新しいサブコマンドが追加されました。これらのコマンド、create、delete、update、rename は、Git にとっては驚くかもしれませんが、名前が示唆する通りのことを行います。ユーザビリティの微調整がいくつかあります。git branch の新しい --delete-merged オプションは、リモート追跡ブランチにマージされたローカルブランチを削除します。git branch -d を使用してブランチを削除しようとすると、そのブランチがバイセクションに使用されている場合、有用なメッセージとともに失敗します。設定ファイルをロックしようとすると、複数のコマンドが同時にファイルを変更しようとしたときの煩わしさを回避するために、失敗時にリトライが行われます。git add には、マージコンフリクトが解決されたファイルのみを追加する新しい --resolved オプションがあります。それ以外にも、いつものようにバグ修正、リファクタリング、パフォーマンス改善の長いリストがあります。全体として、2.56 は堅実なリリースのように見えますが、プロジェクトがより重要な作業の多くを将来のために保留している兆候も示しています。それは、次に何が来るかという疑問につながります。2.56 の後？ 9 月初旬、Git のメンテナーである Junio Hamano は、次のリリースをどうすべきかコミュニティに尋ねました。コミュニティがしばらくの間取り組んできた 3.0 リリースを出し、良い形で年を締めくくるのが最善でしょうか？それとも、3.0 リリースが可能になる前に、まだ 2.x リリースが 1 つ以上必要でしょうか？これは重要な質問です。なぜなら、3.0 には多くの互換性のブレークが含まれており、一部のユーザーはアップグレードをためらう可能性があるからです。その中でも、おそらく最も重要なのは、デフォルトで SHA-1 ハッシュ関数ではなく、Git が当初から使用してきた SHA-1 ハッシュ関数から SHA-256 ハッシュ関数への切り替えです。SHA-1 は長い間弱いと見なされており、Git のようなアプリケーションにとっては懸念事項です。ハッシュは、Git リポジトリ内のすべてのオブジェクト（ファイル、ディレクトリツリー、コミット）を識別するために使用され、任意の時点につながるコミットのチェーンを検証するために使用されます。SHA-1 が破られると、リポジトリの履歴を検出が困難または不可能な方法で変更するために使用される可能性があります。Git には長い間、既知の SHA-1 攻撃に対する防御策が含まれており、現在、リポジトリが侵害される可能性について真剣に心配している人はほとんどいないようです。それでも、より安全なハッシュ関数に移行することは理にかなっています。Git 2.42 リリース（2023年）以降、SHA-256 の非実験的サポートは Git に存在していますが、古いリポジトリとの相互運用性のためのいくつかのグルーコードには時間がかかっています。Git 開発者がしばらくの間、デフォルトで SHA-256 に移行するのを妨げてきた最大の懸念は、主要なフォージサイトでのサポート（またはその欠如）でした。GitLab は 2024 年からサポートしており、Forgejo もサポートしています。しかし、まだこの部屋にいない象は GitHub です。GitHub と互換性のないリポジトリを作成するバージョンの Git をリリースすることは、懸念される見通しです。GitHub がいつそのサポートを追加するかはまだ明らかではありませんが、GitHub の従業員であり SHA-256 移行の主要な開発者である brian m. carlson が、そのトピックに関するニュースが間もなく発表され、次のリリースを 3.0 にすることが最善の選択肢かもしれないと Hamano の質問に答えたことは注目に値します。とはいえ、carlson は、3.0 がリリースされる前に追加したいもう 1 つの変更を投稿しました。Git は常に 16 進数（特にオブジェクト ID）を小文字の文字列として管理してきましたが、大文字の ID も受け入れてきました。これにより、一見異なる 2 つの ID（例えば f00f00 と F00F00）が実際には同じであるという状況が生じます。どうやら、この曖昧さからバグやセキュリティ上の脆弱性が生じているようです。そのため、carlson は Git の動作を変更して、ID を小文字のみで受け入れるようにしたいと考えています。これは、多くのユーザーに問題を引き起こさないはずの変更ですが、その動作に依存している人がどこかに必ずいるはずです。3.0 リリースを待っているもう 1 つの重要な変更は、「reftable」メカニズムへの切り替えです。Git における参照（より一般的には「ref」）は、リポジトリ内の名前とオブジェクトとの関連付けです。たとえば、ブランチ、タグ、リモートはすべて ref です。Git は現在（デフォルトで）各 ref をリポジトリ内の .git/refs/ の下にファイルとして格納しています。リポジトリに foo という名前のブランチがある場合、そのブランチの先頭にあるコミットの ID を含むファイル .git/refs/heads/foo が存在します。これらの ref をすべて packed-refs ファイルにまとめるメカニズムもありますが、これはパフォーマンスを向上させます。このメカニズムは機能しますが、ref の数が増えるにつれて非効率的になります。一部のプロジェクトでは、ref の数が実際に増加します。プロジェクトの reftable ドキュメントによると、Android リポジトリには 800,000 を超える ref が含まれています。その規模では、ref を検索したり、特定のコミットを指す ref が存在するかどうかを判断したりすることは、コストのかかる操作になる可能性があります。開発の遅延は黄色信号レベルの煩わしさにつながる可能性があり、ref について何かを行う必要性が生じます。Git 2.45 リリースでは、ref を格納するためのより効率的な方法として reftables が追加されました。これは、スペース効率と高速アクセスの両方に最適化されたバイナリファイルです。それ以来、古いファイルベースのメカニズムではなく reftable を使用するリポジトリを作成することが可能になりましたが、それはデフォルトではありませんでした。reftable への切り替えは、Git 自体のユーザーにとっては（パフォーマンスの向上以外に）目に見える影響はありませんが、Git リポジトリにアクセスする他のソフトウェアパッケージのユーザーにとっては問題となる可能性があります。彼のメールで、carlson は libgit2 を潜在的な懸念事項として言及しました。結果として、libgit2 はここではブロッカーにはならないでしょう。Patrick Steinhardt は、libgit2 に reftable サポートを追加したこと、そして 8 月に SHA-256 サポートがデフォルトで有効になったことを知らせました。したがって、libgit2 は Git 3.0 への移行準備ができているはずです。最後に、carlson が言及したように、Rust の問題があります。プロジェクトは Rust で書かれたコードの試用サポートを追加しましたが、Git のビルドに Rust を必須にすることにはためらってきました。それも 3.0 リリースで変更される予定です。その後、動作する Rust コンパイラがないプラットフォームはアップグレードできなくなります。これらの懸念事項をリストアップした後、carlson