Git 2.56 および 3.0 への展望

Git 2.56 — そして 3.0 に期待すること

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](https://git-scm.com/docs/git-branch) の新しい --delete-merged オプションは、リモート追跡ブランチにマージされたローカルブランチを削除します。git branch -d でブランチを削除しようとした場合、そのブランチがバイセクションに使用されていると、有用なメッセージとともに失敗します。設定ファイルをロックしようとすると、複数のコマンドが同時にファイルを変更しようとした際の煩わしさを回避するために、失敗した場合にリトライが行われます。[git add](https://git-scm.com/docs/git-add) には、マージコンフリクトが解決されたファイルのみを追加する新しい --resolved オプションがあります。

それ以外にも、通常のバグ修正、リファクタリング、パフォーマンス改善の長いリストがあります。全体として、2.56 は堅実なリリースに見えますが、プロジェクトがより重要な作業の多くを将来のために保留している兆候も示しています。それは、次に何が来るかという疑問につながります。

2.56 の後？

9月初旬、Git のメンテナーである Junio Hamano は、次のリリースをどうすべきかコミュニティに尋ねました。コミュニティがしばらくの間取り組んできた 3.0 リリースを、良い形で年を締めくくるために出すべきか？それとも、3.0 リリースが可能になる前に、まだ 2.x リリースが 1 つ以上必要か？

これは重要な質問です。なぜなら、3.0 には多くの互換性のブレークが含まれており、一部のユーザーはアップグレードをためらう可能性があるからです。その中でもおそらく最も重要なのは、Git が当初から使用してきた SHA-1 ハッシュ関数の代わりに、デフォルトで SHA-256 ハッシュ関数を使用するようになることです。SHA-1 は長い間脆弱であると見なされており、Git のようなアプリケーションにとっては懸念事項です。ハッシュは、Git リポジトリ内のすべてのオブジェクト (ファイル、ディレクトリツリー、コミット) を識別するために使用され、任意の時点までのコミットチェーンを検証するために使用されます。SHA-1 が破られると、リポジトリの履歴を検出が困難または不可能な方法で改変するために使用される可能性があります。

Git には SHA-1 攻撃に対する防御策が長らく組み込まれており、現在、侵害されたリポジトリの可能性について真剣に心配している人はほとんどいないようです。それでも、より安全なハッシュ関数に移行することは理にかなっています。

SHA-256 の非実験的なサポートは、2023 年の Git 2.42 リリース以降存在していますが、古いリポジトリとの相互運用性のためのいくつかの連携には時間がかかっています。Git 開発者がしばらくの間、デフォルトで SHA-256 に移行できなかった最大の懸念は、主要なフォージサイトでのサポート (またはその欠如) でした。GitLab は 2024 年からサポートしており、Forgejo もサポートしています。しかし、まだこの部屋にいない象は GitHub です。GitHub と互換性のないリポジトリを作成する Git のバージョンをリリースすることは、懸念される見通しです。GitHub がいつそのサポートを追加するかはまだ明らかではありませんが、GitHub の従業員であり SHA-256 移行の主要な開発者である brian m. carlson が、Hamano の質問に対し、そのトピックに関するニュースが間もなく発表されること、そして次のリリースを 3.0 にすることが最善の選択肢かもしれないと応答したことは注目に値します。

とはいえ、carlson は 3.0 がリリースされる前に追加したいと考えるもう一つの変更を投稿しました。Git は常に 16 進数の数値 (特にオブジェクト ID) を小文字の文字列として管理してきましたが、大文字の ID も受け入れてきました。これにより、f00f00 と F00F00 のように、一見異なる 2 つの ID が実際には同じであるという状況が発生します。どうやら、この曖昧さからバグやセキュリティ上の脆弱性が生じているようです。そのため、carlson は Git の動作を変更して、ID を小文字のみで受け入れるようにしたいと考えています。これは、あまり多くのユーザーに問題を引き起こさないはずの変更ですが、その動作に依存している人がどこかに必ずいるはずです。

3.0 リリースを待っているもう一つの重要な変更は、「reftable」メカニズムへの切り替えです。Git における参照 (より一般的には「ref」) とは、リポジトリ内のオブジェクトと名前の関連付けです。例えば、ブランチ、タグ、リモートはすべて ref です。Git は現在 (デフォルトで) 各 ref をリポジトリ内の .git/refs/ の下のファイルとして保存しています。リポジトリに foo という名前のブランチが含まれている場合、.git/refs/heads/foo というファイルがあり、そのブランチの先頭のコミット ID が含まれています。パフォーマンスを向上させるための、これらの ref をすべて packed-refs ファイルにまとめるメカニズムもあります — ある程度までは。

このメカニズムは機能しますが、ref の数が増えるにつれて非効率的になります。一部のプロジェクトでは、ref の数は実際に増加します。プロジェクトのreftable ドキュメントによると、Android リポジトリには 80 万以上の ref が含まれています。その規模では、ref を検索したり、特定のコミットを指す ref が存在するかどうかを判断したりすることは、高コストな操作になり得ます。開発の遅延は、黄色カードレベルの迷惑となり、何らかの対策を講じたいという欲求につながります。

Git 2.45 リリースでは、ref をより効率的に保存する方法として reftable が追加されました。これは、スペース効率と高速アクセス用に最適化されたバイナリファイルです。それ以来、古いファイルベースのメカニズムではなく reftable を使用するリポジトリを作成することが可能になりましたが、それはデフォルトではありませんでした。reftable への切り替えは、Git 自体のユーザーにとっては (パフォーマンス向上以外の) 可視的な影響はないはずですが、Git リポジトリにアクセスする他のソフトウェアパッケージのユーザーにとっては問題となる可能性があります。彼のメールで、carlson は libgit2 を潜在的な懸念事項として言及しました。

結果として、libgit2 はここではブロッカーにはならないでしょう。Patrick Steinhardt は、libgit2 に reftable サポートを追加したこと、そして SHA-256 サポートが 8 月にデフォルトで有効になったことを知らせました。したがって、libgit2 は Git 3.0 移行の準備ができているはずです。

最後に、carlson が言及したように、Rust の問題があります。プロジェクトは、Rust で書かれたコードのトライアルサポートを追加しましたが、Git のビルドに Rust を必須にすることにはためらってきました。これもまた、3.0 リリースで変更されると予想されます。それ以降、動作する Rust コンパイラを持たないプラットフォームは、アップグレードできなくなります。

これらの懸念事項をリストアップした後、carlson は、おそらく 3.0 リリースを遅らせるべきではないと提案しました。

SHA-256 (およびローカルリポジトリを扱うソフトウェア向けの reftable) で既に非常に進んでいる人以外は、おそらく考慮する価値はないと思います。例えば、JGit と Gitoxide は両方とも、1 年以上前に Git 3.0 で SHA-256 が登場することを知らされていました。(私が知らせたので知っています)

同様に、Rust サポートをまだサポートしていないプラットフォームで真剣に取り組んでいる人はいないと認識しているので、それもブロッカーになるとは思いません。

これが彼らの結論につながりました。最も可能性が高いのは、次のリリースを 3.0 と指定することが最善の選択肢であるということです。

実際に何が起こるかは、まだ公に発表されていません。それは Hamano が決定を下すのを待っています。彼が言ったように、「これは人気投票ではなく、民主主義でもありません」。しかし、彼の質問が投稿されてから約 2 週間、Git の初期設計上の決定の一部を置き去りにして 3.x 時代に進むことに対して、強い反対意見はありませんでした (もちろん、SHA-1 を使用し、reftable を欠くリポジトリは引き続き完全にサポートされます)。もし 3.0 リリースが 2026 年に実現しない場合でも、その直後に登場することは確実でしょう。

更新: Kernel Recipes で、Steinhardt はリリースに関する合意された計画を説明しました。2026 年 12 月のリリースは、3.0 移行が近づいていることを示すために 2.98 と呼ばれます。2.99 リリースは 2027 年 4 月に続き、これは長期サポートリリースとなります。Git 3.0 も同時にリリースされ、それ以降のすべてのリリースの基盤となります。