Git 2.52.0の新機能と変更点｜git last-modified・git repo・geometric保守とその後の修正

Git 2.52.0は2025年11月17日に公開されたリリースです。GitHubの解説によると、94人を超える開発者が参加し、そのうち33人が初めての貢献者でした。この記事では、2.52.0と2.56.0をそれぞれソースからビルドし、2.52で入った変更を出力つきで整理します。後の版で直った2.52の不具合も、同じ手順で両方を動かして確かめました。

2.52はすでに最新版ではありません。2026年11月10日時点の最新は2026年9月28日公開の2.56.0です。現在の最新バージョンと更新手順はGitの最新バージョンと確認・アップデート方法にまとめています。この記事は「2.52で何が変わったか」と「2.52を使い続けてよいか」の判断材料に絞っています。

まとめ：Git 2.52.0の要点

• 公開日は2025年11月17日。前の2.51.0は2025年8月18日、次の2.53.0は2026年2月2日です。2.52.1などの保守リリースはありません。
• 目玉はファイルごとの最終変更コミットを一括で出す git last-modified。jqリポジトリ（433ファイル）で、ファイルごとに git log -1 を回す方法の19.7秒に対して0.23秒でした。
• リポジトリの性質を問い合わせる git repo info と、参照・オブジェクトの件数を数える git repo structure が入りました。どちらも git last-modified と同じく実験的扱いです。
• git maintenance に geometric 戦略が加わりました。2.54からは手動保守の既定がこの戦略に変わっています。
• 2.52.0の git last-modified には、sparse-checkoutの対象外パスを指定すると失敗する不具合と、ツリーを渡すとBUGで落ちる不具合があります。前者は2.53.0、後者は2.54.0で直りました。
• Git 3.0で既定ブランチ名が main になることが明記されました。2.52自体の既定は master のままです。

Git 2.52.0のリリース日と前後の版

Gitの機能リリースはおおむね12週間おきです。2.52.0の前後は次のとおりです。日付はgit/gitリポジトリのタグとGit for Windowsのリリースから取りました。

手元の版は git --version で確認できます。Windowsでは git version 2.52.0.windows.1 のように末尾にWindows版の改版番号が付きます。英語の公式リリースノートは git/git リポジトリのDocumentation/RelNotes/2.52.0.adocです。

git last-modified：ファイルごとの最終変更コミットを一括取得

git last-modified は、指定したパスを最後に変更したコミットをまとめて返すコマンドです。GitHubが「blame-tree」という名前で社内のGitに持っていた機能で、2012年からGitHubのファイル一覧に出る「最終コミット」の表示を支えてきました。GitLabの開発者がパッチを整理し、2.52で本家に入りました。公式マニュアルには「THIS COMMAND IS EXPERIMENTAL」と書かれており、挙動は今後変わる可能性があります。

git last-modifiedの基本操作と出力形式

引数なしで実行すると、カレントディレクトリ直下の各エントリについて「コミットIDとパス」をタブ区切りで出します。3回コミットしたテスト用リポジトリで実行した結果です。

$ git log --oneline
3cbd981 update guide
47c6839 fix app
330151f initial

$ git last-modified
3cbd981ef4f7cab308717d1239f4900097cbeec9	docs
47c68392dc8a788e63a0596ef7f6b154b33a6a8e	src
330151f3102e36a91ddd4e1feee2e6057f50662e	README.md

コミットIDは省略されず、このSHA-1リポジトリでは40桁で出るので、日付や作者が必要なら git show -s --format=... に渡して引きます。リネームとファイルモードの変更も「変更」として数えます。

git last-modifiedの再帰・パス指定・履歴範囲指定

範囲を絞ると、範囲内で変更されていないパスは先頭に ^ の付いた境界コミットで表示されます。「この範囲で触ったかどうか」を判定するときは、この記号で分けられます。

$ git last-modified HEAD~1..
3cbd981ef4f7cab308717d1239f4900097cbeec9	docs
^47c68392dc8a788e63a0596ef7f6b154b33a6a8e	README.md
^47c68392dc8a788e63a0596ef7f6b154b33a6a8e	src

2.52.0では、作業ツリーに無いパスを指定すると -- で区切っても失敗します。sparse-checkoutで外したディレクトリを調べるときに当たる不具合で、詳しくは後述の「2.52で入った機能のその後」で扱います。

git log -1 をパスごとに回す方法との速度差

従来は git ls-tree でパスを列挙し、パスごとに git log -1 -- <path> を実行していました。この方法はパスの数だけ履歴をたどり直します。jqのリポジトリ（検証コミットf13c1ef、blobless clone、1,954コミット、直下27エントリ、全433ファイル）で5回ずつ実行した中央値は次のとおりです（2026年10月5日計測）。直下27エントリの結果は両方式で一致しました。

計測環境はIntel Core i9-9880HのmacOSです。今回の全433ファイルでの所要時間比は約85倍でした。GitHubの解説記事には5.48倍（3.962秒対722.7ミリ秒）という別の測定結果もありますが、対象リポジトリや測定条件が異なるため、倍率を直接比較することはできません。ファイル一覧に最終更新日を付けるツールや、長く触られていないファイルを洗い出すスクリプトで効きます。行単位の履歴は従来どおり git blame です。

git repo info・git repo structure：リポジトリ情報の取得

git repo も2.52で入った実験的コマンドです。これまで git rev-parse のオプションに散らばっていた「このリポジトリはbareか」「ハッシュ方式は何か」といった問い合わせを、1つのコマンドに集める第一歩とされています。

git repo info で使えるキー

2.52.0で使えるキーは layout.bare・layout.shallow・object.format・references.format の4つです。指定した順に キー=値 で返ります。

$ git repo info layout.bare layout.shallow object.format references.format
layout.bare=false
layout.shallow=false
object.format=sha1
references.format=files

-z（--format=nul と同じ）を付けると、値が引用符で囲まれずNUL文字で区切られるので、スクリプトで読むならこちらが向きます。object.format が sha256、references.format が reftable のリポジトリを扱うCIでは、分岐の判定にこのキーを使えます。2.52.0には全キーを一度に出す --all もキー一覧を出す --keys も無く、キーは名前を知っている前提で指定します。

git repo structureによる参照数・オブジェクト数の取得

git repo structure は、ブランチ・タグ・リモート参照の件数と、到達可能なコミット・ツリー・ブロブ・タグの件数を数えます。

$ git repo structure --format=keyvalue
references.branches.count=1
references.tags.count=0
references.remotes.count=0
references.others.count=0
objects.commits.count=3
objects.trees.count=7
objects.blobs.count=5
objects.tags.count=0

既定の表形式（table）について、マニュアルは「形式が変わることがあり、機械処理向けではない」と明記しています。監視やレポートに組み込むなら、2.52では --format=keyvalue か --format=nul を指定してください。2.54以降では形式名が keyvalue から lines に変わるため、両版に対応するなら --format=nul を使います。大きなモノレポで参照数の増え方を追う用途に向いています。

git maintenance の geometric 戦略

git maintenance は、パックファイルの整理やcommit-graphの更新をまとめて行うコマンドです。2.52で戦略（maintenance.strategy）に geometric が加わりました。2.52.0時点の位置づけは次のとおりです。

geometric は、パックファイルをオブジェクト数の幾何級数になるようにまとめ、全体を1つに詰め直す処理をできるだけ避けます。全体を詰め直すことになる場合だけ、到達不能なオブジェクトをcruft packへ分けて整理します。マニュアルは gc 戦略の完全な代替で、大きなリポジトリに推奨と書いています。incremental の定期実行は到達不能オブジェクトを削除しないため、それだけに任せると不要なデータが溜まります。geometric はその穴を埋める位置づけです。

$ git config maintenance.strategy geometric
$ git maintenance run
$ ls .git/objects/pack
multi-pack-index
pack-2c7701f0f37020886c6b917afe691409638a8cdf.idx
pack-2c7701f0f37020886c6b917afe691409638a8cdf.pack
pack-2c7701f0f37020886c6b917afe691409638a8cdf.rev

実行後はルーズオブジェクトが0件になり、パックとmulti-pack-indexが作られました。調整用の設定は maintenance.geometric-repack.auto（既定100）と maintenance.geometric-repack.splitFactor（既定2）です。数GB規模のリポジトリで git gc に毎回時間を取られているなら、まず試す価値があります。小さなリポジトリで保守時間や容量に問題がなければ、既定のままで構いません。

その他の新コマンド・設定と操作の変更

リリースノートから、日常の操作に関わるものを抜き出しました。

git refs exists と diff-tree –max-depth の動作

git refs exists は git show-ref --exists と同じ働きで、参照があれば終了コード0、無ければ2を返します。シェルスクリプトでブランチの有無を確かめる処理が短くなります。

$ git refs exists refs/heads/master; echo $?
0
$ git refs exists refs/heads/nope; echo $?
error: reference does not exist
2

git diff-tree -r --max-depth=0 --name-only HEAD~2 HEAD は、この検証例では変更のあったトップレベルのディレクトリ名を返します。直下のファイルに変更があれば、そのファイル名も対象です。--max-depth=1 にすると、その1階層下のファイルまで出ます。モノレポで「どのパッケージに変更があったか」を取り出すときに使えます。

stash.indexによるpop時のステージ状態の復元

git stash pop は既定でも変更内容を復元しますが、退避前のステージ状態は復元しません。stash.index をtrueにすると、毎回 --index を付けたのと同じ動作になります。README.mdの一部をステージし、残りを未ステージのままstashして戻した結果です。

# stash.index=false（既定）
$ git status --short
 M README.md

# stash.index=true
$ git status --short
MM README.md

この設定は git rebase --autostash や git pull --autostash の自動退避にも効きます。stashの後始末についてはgit stashの削除と復元の手順で扱っています。

git fast-import の署名付きコミット・タグの扱い

2.52で git fast-import が --signed-commits と --signed-tags を受け付けるようになりました。値は verbatim・warn-verbatim・warn-strip・strip・abort の5つで、既定は署名をそのまま取り込む verbatim です（v2.52.0のgit-fast-importマニュアル）。履歴を書き換えて取り込むと元の署名は検証に通らなくなるため、移行ツールの側で署名を落とすかどうかを選べるようになりました。SSH鍵で署名したコミットを fast-export から流し込み、strip で取り込んだ結果です。

$ git cat-file commit HEAD | grep -c gpgsig
1
$ (cd r && git fast-export --signed-commits=verbatim main) \
  | (cd dst && git fast-import --quiet --signed-commits=strip)
$ cd dst && git cat-file commit main | grep -c gpgsig
0

取り込み先のコミットから gpgsig ヘッダーが消え、署名ヘッダーの分だけ中身が変わるのでコミットIDも変わりました（元のcf2d7baが取り込み先では16ec2ef）。両側を verbatim にすれば、2.52.0でも署名とコミットID（cf2d7ba）はそのまま残りました。無効な署名だけを落とす strip-if-invalid は2.53、書き換えで無効になった署名を付け直す機能は2.54で加わったので、履歴を書き換えながら署名を活かしたいならそれ以降の版が必要です。

Git 2.52の処理速度改善と不具合修正

ワイルドカードを含むパス指定（例：git log 'src/*/test'）でも、変更パスのBloomフィルタが使えるようになりました。これまではパス指定にワイルドカードが入るとフィルタが使われていませんでした。Bloomフィルタはcommit-graphに書き込まれるもので、上の表の commitGraph.changedPaths をtrueにすると、git commit-graph write に毎回 --changed-paths を付けたのと同じになります。GitHubによると、git describe は優先度付きキューの導入で約30%速くなっています。このほか、マージコミットを含む git log -L の高速化、git remote rename での参照の付け替えの効率化、git ls-files がスパースインデックスを展開せずに済む場面の拡大が入りました。

修正では、対話的rebaseでマージコミットに drop を指定したときの不具合や、git remote rename origin upstream で origin/HEAD が移らない問題が直っています。

2.52で入った機能のその後：2.53〜2.56での修正と既定値の変更

2.52で入った新コマンドは、その後の機能リリースで不具合の修正と機能追加が続いています。2.53.0〜2.56.0のリリースノートから該当する項目を拾い、2.52.0と2.56.0を同じ手順でビルドして同じ操作を実行しました（2026年11月10日、macOS）。

sparse-checkoutの対象外パスで失敗する不具合

マニュアルは -- でリビジョンとパスを区切る使い方を案内していますが、2.52.0では作業ツリーに無いパスを渡すと区切っても通りません。src だけをsparse-checkoutした状態で、外した docs を調べた結果です。

$ git sparse-checkout set src
$ git last-modified -- docs     # 2.52.0
fatal: ambiguous argument 'docs': unknown revision or path not in the working tree.
$ git last-modified -- docs     # 2.56.0
f81d24e94a21573e57366dff48fe62bc981df471	docs

この修正はコミット05491b90ceで、Git for Windowsへの不具合報告を受けたものです。2.53.0のリリースノートに載っています。モノレポでsparse-checkoutを使いながら、外したパッケージの最終更新を一覧にする用途は2.52では動きません。

ツリーを渡すとBUGで落ちる不具合

コミットでなくツリーを指定すると、2.52.0は内部の整合性チェックに引っかかって異常終了します。終了コードは134（SIGABRT）でした。2.54.0以降は通常のエラーメッセージを出して終了します。

$ git last-modified 'HEAD^{tree}'     # 2.52.0
BUG: builtin/last-modified.c:456: paths remaining beyond boundary in last-modified
$ git last-modified 'HEAD^{tree}'     # 2.56.0
error: revision argument 'HEAD^{tree}' is a tree, not a commit-ish

注釈付きタグはコミットへ辿れるので、2.54.0以降は問題なく渡せます（コミット525ef52301）。利用者の入力をそのまま渡す社内ツールを2.52で動かすなら、渡す前に git rev-parse --verify '<rev>^{commit}' でコミットかどうかを確かめておくと、BUGでの異常終了を避けられます。

git repo info のキー追加と maintenance の既定変更

git repo info は2.53.0で全キーを出す --all、2.54.0で使えるキーを並べる --keys を覚え、2.56.0では path.gitdir.absolute や path.commondir.relative など、git rev-parse --git-dir・--git-common-dir に当たる4キーが加わりました。2.56.0の --keys は8キーを返します。2.52.0向けに書いたスクリプトも、4キーを名前で指定し --format を付けていなければ2.56.0でそのまま動きます。--format=keyvalue を付けていると、2.56.0では fatal: invalid format 'keyvalue'（終了コード128）で止まりました。

保守の既定は2.54.0で変わりました。v2.54.0のmaintenance設定の説明は、geometric を「手動保守の既定の戦略」と書いています。設定なしで git maintenance run を実行すると、2.52.0ではパックだけが作られ、2.56.0では multi-pack-index も作られました。2.52のまま大きなリポジトリを保守するなら、maintenance.strategy=geometric を自分で設定する必要があります。

Git 3.0に向けて2.52で入った予告と下準備

既定ブランチ名 main の予告

2.52のリリースノートは、設定の無い git init がGit 3.0から main を使うと宣言しました。2.52.0で設定なしに git init すると、次のヒントが表示され、ブランチは master で作られます。

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>

CIやテンプレートで master を前提にしているなら、今のうちに git config --global init.defaultBranch master で明示しておくと、3.0に上げたときに挙動が変わりません。

SHA-256相互運用とRustの導入

Git 3.0では、新規リポジトリの既定ハッシュがSHA-1からSHA-256へ変わる予定です。2.52では、SHA-1のリポジトリとSHA-256のリポジトリの間でpush・pullできるようにする相互運用の作業が始まりました。入ったのは土台の部分だけで、利用者が使える機能はまだありません。

Rustについては、Git本体の内部処理にRust実装を任意で使う初めての版です。Makefileでのビルドでは WITH_RUST=YesPlease を指定すると、可変長整数の符号化と復号にRust実装が使われます。MesonでのビルドではRustの利用可否が自動検出されます。Rustは2.52では任意ですが、Git 3.0ではビルドの必須要件になる計画です。

Git 3.0の参照形式変更と削除予定機能

2.52.0同梱のBreakingChanges文書は、3.0で既定の参照形式を files から reftable へ切り替えるとしています。削除予定には、シンボリックリンクで書くシンボリック参照（core.preferSymlinkRefs=true）、core.commentString=auto、git whatchanged（代わりは git log --raw）が並びます。Git for Windows 2.52.0で git svn のサポートが終わったのはWindows版の判断で、Git本体の変更ではありません。3.0の公開日は決まっていません。

Git 2.52を入れる方法：OS別の入手経路

2.52をそのまま入れられる経路は限られます。各OSの標準パッケージは2.52を飛ばしているか、すでに新しい版に移っているためです。

Windows：通常版2.52.0とMinGit 2.52.0(2)の違い

通常のインストーラーは、2025年11月17日公開のGit for Windows 2.52.0に Git-2.52.0-64-bit.exe と Git-2.52.0-arm64.exe として残っています。2026年3月10日に出たMinGit for Windows 2.52.0(2)は、アプリへの組み込み用の最小構成であるMinGitだけのプレリリースで、通常のインストーラーはありません。この版はCVE-2025-66413の修正版で、攻撃者のサーバーからcloneしたときにNTLMv2ハッシュが漏れる問題に対し、NTLM認証を既定で無効にしています。通常のインストーラーでこの修正を受けるには、同じ日に公開されたGit for Windows 2.53.0(2)以降へ上げます。Windows版の最新版と更新方法はGit for Windowsの最新版とインストール・更新方法を参照してください。

Ubuntu：標準パッケージの版と2.52の入手経路

2026年11月10日にLaunchpad APIで確認したUbuntu標準リポジトリのgitは、24.04 LTSが2.43.0（1:2.43.0-1ubuntu7.4）、26.04 LTSが2.53.0、26.10が2.55.0です。サポート中のどの版も2.52ではありません。git-core PPAは2025年11月18日に22.04・24.04・25.04・25.10・26.04向けへ2.52.0を出しましたが、いまも2.52.0が残っているのはサポートが終わった25.04向けだけです。22.04・24.04・26.04・26.10向けは2026年10月23日から2.56.0に置き換わっています（いずれもLaunchpad APIの公開履歴で確認）。Ubuntuで2.52を使いたい場合は、次のソースビルドになります。

macOS・Linux共通：Git 2.52.0のソースビルド

Homebrewのgitは最新版（2026年11月10日時点で2.56.0）だけを提供しています。Xcodeのコマンドラインツールに入っているのはAppleが独自にビルドした版（例：git version 2.50.1 (Apple Git-155)）で、本家の版とは揃っていません。特定の版に固定するなら、タグのソースからビルドします。事前にCコンパイラ、make、zlibやlibcurlなどの開発用ライブラリを用意してください。この記事の検証では次の手順でIntel MacにGit 2.52.0を入れました。

curl -sL https://github.com/git/git/archive/refs/tags/v2.52.0.tar.gz -o git-2.52.0.tar.gz
tar xzf git-2.52.0.tar.gz && cd git-2.52.0
make -j4 NO_GETTEXT=1 NO_TCLTK=1 NO_PERL=1 NO_PYTHON=1 prefix=$HOME/.local/git-2.52 all
make NO_GETTEXT=1 NO_TCLTK=1 NO_PERL=1 NO_PYTHON=1 prefix=$HOME/.local/git-2.52 install
$HOME/.local/git-2.52/bin/git --version   # git version 2.52.0

NO_PERL=1 と NO_PYTHON=1 を付けると、Perlで書かれた git send-email などは入りません。必要なら外してビルドします。システムのgitを置き換えず、別の場所に入れて絶対パスで呼ぶ形にしておくと、検証が終わったあとに消すのも簡単です。2.56.0を同じ手順でビルドするときは、Rustのツールチェーンが無ければ NO_RUST=YesPlease を付けます。

2.52で止めるか上げるかの判断基準

結論から言うと、2.52に留まる理由はほとんどありません。git/gitのタグを見ると、2.51系には2.51.1・2.51.2の保守リリースがありますが、2.52系には2.52.0しかありません。上流で2.52.0の公開後に入った修正は、前章の git last-modified の2件を含めて2.53以降の機能リリースで配られています。例外はWindowsのMinGit 2.52.0(2)で、組み込み用途に限ってセキュリティ修正が出ました。業務の端末やCIのイメージは、その時点の最新版へ上げるのが基本です。

2.52に固定してよいのは、次のような場面に限られます。

• 2.52で起きた不具合や挙動を再現・調査する
• 社内ツールの動作確認を、組み込み先で使用しているMinGit for Windows 2.52.0(2)と同じ版で行う必要がある
• 2.52で入った機能を使う最低バージョンとして、CIで下限を確かめる

3つ目の場面で git last-modified を下限に据えるなら、sparse-checkoutを使うリポジトリでは2.53.0を下限にしてください。2.52.0では前章の不具合で動かないためです。git repo info --keys でキーを確かめる処理を書くなら下限は2.54.0です。

もう1つの注意点は、git last-modified と git repo の出力を前提にした仕組みです。どちらもマニュアルで実験的と明記されています。社内の一覧画面や監視に組み込むなら、出力の解析を1か所に閉じ込め、Gitを上げるたびにそこだけ確かめる作りにしてください。git repo structure の表形式を正規表現で読むような実装は避けます。CIランナーのGitの版をどこで固定し、いつ上げるかを含めたパイプラインの設計は、DevOps・CI/CD導入支援でも相談を受けています。

よくある質問

Git 2.52.0はいつリリースされましたか？

2025年11月17日です。同じ日にGit for Windows 2.52.0(1)も公開されました。次の2.53.0は2026年2月2日に出ています。

Git 2.52の一番大きな変更は何ですか？

新コマンドの git last-modified です。各ファイルを最後に変更したコミットを一括で返し、ファイルごとに git log -1 を回す方法より大幅に速く動きます。ただし実験的扱いで、出力形式が今後変わる可能性があります。2.52.0にはsparse-checkout外のパスで失敗する不具合があり、2.53.0で直りました。

Git 2.52で既定のブランチ名はmainになりましたか？

なっていません。2.52の既定は master のままで、main への変更はGit 3.0からです。2.52では git init のヒントでその予定が告知されます。

git version 2.52.0.windows.1 と .windows.2 の違いは何ですか？

.windows.2は2026年3月10日にMinGit（組み込み用の最小構成）向けだけに出た修正版で、NTLM認証を既定で無効にしてCVE-2025-66413に対処しています。Git本体の中身は同じ2.52.0です。通常のインストーラーは.windows.1までなので、インストーラーで入れた環境は同じ修正を含む2.53.0(2)以降へ上げてください。

Git 2.52から最新版へ上げる方法は？

Windowsは git update-git-for-windows、macOSは brew upgrade git、UbuntuはPPAかソースビルドで更新します。最新の版番号と手順はGitの最新バージョンの確認・アップデート方法を確認してください。

関連記事

• Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点【2026年10月】
• Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法【2026年10月】
• Gitコマンド一覧｜よく使う基本コマンドの早見表と用途別の使い方・トラブル対処【Git 2.56対応】
• Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点
• モノレポ（Monorepo）とは？マルチレポとの違い・メリット・デメリットと導入手順