Git 2.56.0リリース、merge-baseが高速化しrepackが小さく

Git 2.56.0が公開されました。Gitのメンテナーを務めるJunio C Hamano氏が、2026年9月28日にリリースを発表しました。改善の多くは速度とディスク容量に関するものです。Linuxカーネルでのあるmerge-baseの問い合わせは、167,441ステップではなく3,887ステップで済むようになりました。リポジトリをpackする新しい方法により、ある大きなテスト用リポジトリが71%小さくなりました。

Hamano氏の発表によると、このリリースには、6月に公開されたGit 2.55以降のマージ以外のコミットが748件含まれます。これらは104人の開発者によるもので、そのうち39人は初めてGitに貢献しました。

Tech AI Wireは先週、リリース候補をもとに新しいコマンドを先取りして紹介しました。git history dropやgit branch --delete-mergedなどです。本記事では、最終版のリリースノート、GitHub、GitLabがそれに加えて伝えている内容を扱います。

merge-baseが最大70倍高速に

merge baseとは、2つのブランチが共有する最も新しいコミットのことです。Gitは、マージやリベースをするたびに、またブランチがmainからどれだけ離れたかを確かめるたびに、これを求めます。大きなリポジトリでは、履歴をさかのぼるこの探索が遅くなることがあります。

Git 2.56は探索を早めに打ち切ります。Hamano氏の発表によると、Gitは今後「キュー内にある一方の側の固有のコミットが尽きた時点で」停止します。簡単に言えば、一方のブランチにもう提供できるものがないとGitが証明できた時点で、探索をやめるということです。

GitHubのハイライト記事は、この変化を数字で示しています。Linuxカーネルでのmerge-baseの問い合わせは、167,441ステップで0.29秒かかっていたものが、3,887ステップで0.01秒になりました。GitHubが2つの大規模なモノレポで計測したところ、一方では70倍、もう一方では平均20倍の高速化が見られました。

関連する変更として、git branch --containsなどのコマンド内で以前の結果を再利用するようになりました。このコマンドは、指定したコミットを含むブランチを一覧表示します。これにより、あるコミットから別のコミットに到達できるかをGitが確かめる処理が速くなります。

path-walkによるrepackでリポジトリが小さく

Gitは履歴をpackファイルに保存します。packファイルは、オブジェクトを圧縮してまとめたものです。repackは、容量を節約するためにそのまとまりを書き直します。--path-walkオプションは、圧縮の前にファイルパスごとにオブジェクトを集めます。そのため、同じファイルの各バージョン同士が比較されます。

GitHubがFluent UIのリポジトリで行ったテストでは、packが558.5MBから164.4MBに縮みました。約71%の縮小です。2.56では、path-walkによるrepackがreachability bitmapとdelta islandにも対応しました。Gitサーバーはこの2つの機能を使って、クローンを素早く開始し、ストレージを共有するフォーク同士を分けて保ちます。

部分クローンで再び大きなファイルを手放せるように

部分クローン(partial clone)は、大きなファイルをすべて取得せずに履歴をダウンロードします。ファイルの中身を指すGitの用語であるblobは、コマンドが必要としたときにだけ取得されます。時間がたつと、取得したファイルがディスクにたまっていきます。

Git 2.56では、それらを削除する方法が加わりました。リリースの発表によると、git repackに--drop-filteredを付けると、サイズの上限を超えるローカルのblobのうち、サーバーが引き続き提供できるものが削除されます。GitHubの記事には完全な例が載っています。git repack -a --filter=blob:limit=1m --drop-filteredです。これは手動の手順であり、自動の掃除ではありません。

より安全な競合解消と見やすいログ

git add --resolvedは、マージの競合を解消したファイルだけをステージします。最終版ではさらに、それらのファイルに競合マーカーが残っていないかも確認します。競合マーカーとは、競合したファイルにGitが書き込む<<<<<<<の行のことです。これにより、直しかけのファイルがコミットに紛れ込みにくくなります。

git log --followは、複数の名前変更やマージを含む履歴でも、以前よりうまくファイルを追跡するようになりました。git log --graphは、親を持たないルートコミットをインデントし、別々の履歴が目立つようにします。この動作は--no-graph-indentフラグかlog.graphIndent設定で制御できます。

2.56の次に来るもの

次のバージョンは2.57にはなりません。GitLabのエンジニアであるKarthik Nayak氏によると、Gitは2026年12月に2.98へ飛ぶ計画です。Git 2.99とGit 3.0は2027年春の予定です。「この大きな飛躍は、ダウンストリームのメンテナーと利用者の双方に、大きな変更が来ることを示す合図になります」とNayak氏は書いています。

その変更とは、Git 3.0でSHA-256とreftableが既定になること、そしてRustがビルドの必須要素になることです。

これは開発者にとって何を意味するか

ほとんどの開発者は、アップグレードするだけでmerge-baseの高速化を得られます。効果が大きいのは、大規模なモノレポや、1日に何度もリベースやブランチ比較を行うCIジョブです。パイプラインがコンテナイメージの中で古いGitに固定されているなら、その固定こそが恩恵を妨げています。

次にマージが競合で止まったときは、git add --resolvedを試してください。マージの途中でgit add .を実行する習慣の代わりになります。git add .は、修正と一緒に作業ツリー内の余計な編集まですべてステージしてしまいます。

Gitサーバーを運用している場合や大きなミラーを保持している場合は、1つのリポジトリのコピーで--path-walkを試し、packのサイズを比べてください。Fluent UIの結果は1つのリポジトリから得られたもので、皆さんのファイルの構成はそれとは異なるはずです。本番のrepackジョブを変更する前に、計測してください。

最後に、バージョンの飛躍に備えてください。git --versionの出力を比較し、次は2.57だと想定しているスクリプトは、代わりに2.98に出会うことになります。変更がまだ数か月先の今のうちに、そうした比較を確認しておきましょう。