--- title: "Git 2.52.0の新機能と変更点｜git last-modified・git repo・geometric保守とその後の修正" url: "https://www.issoh.co.jp/tech/details/10466/" published: 2026-01-05 updated: 2026-11-10 categories: ["GitHub"] publisher: "株式会社一創" --- # Git 2.52.0の新機能と変更点｜git last-modified・git repo・geometric保守とその後の修正 Git 2.52.0は2025年11月17日に公開されたリリースです。[GitHubの解説](https://github.blog/open-source/git/highlights-from-git-2-52/)によると、94人を超える開発者が参加し、そのうち33人が初めての貢献者でした。この記事では、2.52.0と2.56.0をそれぞれソースからビルドし、2.52で入った変更を出力つきで整理します。後の版で直った2.52の不具合も、同じ手順で両方を動かして確かめました。 2.52はすでに最新版ではありません。2026年11月10日時点の最新は2026年9月28日公開の2.56.0です。現在の最新バージョンと更新手順は[Gitの最新バージョンと確認・アップデート方法](/tech/details/10164/)にまとめています。この記事は「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のリリースから取りました。 | 版 | 公開日 | 2.52との関係 | | ---------------------------- | ---------- | ------------------ | | 2.51.0 | 2025-08-18 | 直前の機能リリース | | 2.52.0 | 2025-11-17 | 本記事の対象 | | Git for Windows 2.52.0(1) | 2025-11-17 | 本家と同日公開 | | 2.53.0 | 2026-02-02 | 次の機能リリース | | MinGit for Windows 2.52.0(2) | 2026-03-10 | MinGitのセキュリティ修正版 | | 2.54.0 | 2026-04-20 | geometricが手動保守の既定に | | 2.55.0 | 2026-06-29 | – | | 2.56.0 | 2026-09-28 | 2026年11月10日時点の最新 | 手元の版は `git --version` で確認できます。Windowsでは `git version 2.52.0.windows.1` のように末尾にWindows版の改版番号が付きます。英語の公式リリースノートは git/git リポジトリの[Documentation/RelNotes/2.52.0.adoc](https://github.com/git/git/blob/v2.52.0/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の再帰・パス指定・履歴範囲指定 | 指定 | 動作 | | --------------------- | ------------------------ | | `-r` / `--recursive` | サブディレクトリの中まで降りてファイル単位で出す | | `-t` / `--show-trees` | `-r` と併用し、ディレクトリ自体の行も出す | | `-- ` | 指定パスだけを対象にする | | `` | たどる履歴を絞る（既定はHEAD） | 範囲を絞ると、範囲内で変更されていないパスは先頭に `^` の付いた境界コミットで表示されます。「この範囲で触ったかどうか」を判定するときは、この記号で分けられます。 ``` $ 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 -- ` を実行していました。この方法はパスの数だけ履歴をたどり直します。jqのリポジトリ（検証コミットf13c1ef、blobless clone、1,954コミット、直下27エントリ、全433ファイル）で5回ずつ実行した中央値は次のとおりです（2026年10月5日計測）。直下27エントリの結果は両方式で一致しました。 | 対象 | ls-tree＋log -1 | last-modified | | ------------ | -------------- | ------------- | | 直下27エントリ | 1.165秒 | 0.163秒 | | 全433ファイル（-r） | 19.699秒 | 0.232秒 | 計測環境は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時点の位置づけは次のとおりです。 | 戦略 | 主な動作 | 2.52.0での位置づけ | | ------------- | -------------- | ------------------ | | `none` | 何もしない | 定期実行の既定 | | `gc` | gcタスクを実行 | 手動実行の既定 | | `incremental` | 定期実行では小さな作業を分散 | 定期実行ではgcなし・手動実行はgc | | `geometric` | 幾何級数でパックを統合 | 2.52で追加・大規模向け | `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 list` | `git for-each-ref` の窓口として追加 | | `git refs exists` | 参照の有無を終了コードで返す | | `git diff-tree --max-depth` | 差分を表示する階層の深さを指定 | | `stash.index` | trueでpop/applyが常に–index付きになる | | `git fast-import --signed-commits` | 署名付きコミットの扱いを指定 | | `git sparse-checkout clean` | 対象外ディレクトリに残ったファイルを削除 | | `git add -p` | パイプ用の P コマンドを追加 | | `commitGraph.changedPaths` | trueでcommit-graphにBloomフィルタを書く | | `:(optional)` 接頭辞 | パスを取る設定値を「無くてもよい」扱いに | | `git send-email` | 送信済みメールをIMAPフォルダへ保存 | | `core.commentChar=auto` | 非推奨化 | ### 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の削除と復元の手順](/tech/details/18014/)で扱っています。 ### 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マニュアル](https://github.com/git/git/blob/v2.52.0/Documentation/git-fast-import.adoc)）。履歴を書き換えて取り込むと元の署名は検証に通らなくなるため、移行ツールの側で署名を落とすかどうかを選べるようになりました。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）。 | 操作 | 2.52.0 | 2.56.0 | 変わった版 | | -------------------------------------- | -------------- | -------------- | ------ | | sparse外のパスを last-modified | fatalで失敗 | 結果を返す | 2.53.0 | | last-modified にツリーを渡す | BUGで異常終了 | エラーで終了 | 2.54.0 | | `git repo info --all` | unknown option | 全キーを出力 | 2.53.0 | | `git repo info --keys` | unknown option | キー一覧を出力 | 2.54.0 | | `git repo structure --format=keyvalue` | 受け付ける | invalid format | 2.54.0 | | 設定なしの `git maintenance run` | gc戦略 | geometric戦略 | 2.54.0 | ### 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](https://github.com/git/git/commit/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](https://github.com/git/git/commit/525ef52301)）。利用者の入力をそのまま渡す社内ツールを2.52で動かすなら、渡す前に `git rev-parse --verify '^{commit}'` でコミットかどうかを確かめておくと、BUGでの異常終了を避けられます。 ### git repo info のキー追加と maintenance の既定変更 `git repo info` は2.53.0で全キーを出す `--all`、[2.54.0](https://github.com/git/git/blob/v2.54.0/Documentation/RelNotes/2.54.0.adoc)で使えるキーを並べる `--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設定の説明](https://github.com/git/git/blob/v2.54.0/Documentation/config/maintenance.adoc)は、`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 ``` 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](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.1)に `Git-2.52.0-64-bit.exe` と `Git-2.52.0-arm64.exe` として残っています。2026年3月10日に出た[MinGit for Windows 2.52.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.2)は、アプリへの組み込み用の最小構成であるMinGitだけのプレリリースで、通常のインストーラーはありません。この版はCVE-2025-66413の修正版で、攻撃者のサーバーからcloneしたときにNTLMv2ハッシュが漏れる問題に対し、NTLM認証を既定で無効にしています。通常のインストーラーでこの修正を受けるには、同じ日に公開されたGit for Windows 2.53.0(2)以降へ上げます。Windows版の最新版と更新方法は[Git for Windowsの最新版とインストール・更新方法](/tech/details/11868/)を参照してください。 ### 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](https://launchpad.net/~git-core/+archive/ubuntu/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導入支援](/service/system/devops/)でも相談を受けています。 ## よくある質問 ### 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の最新バージョンの確認・アップデート方法](/tech/details/10164/)を確認してください。 ## 関連記事 - [Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点【2026年10月】](/tech/details/10164/) - [Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法【2026年10月】](/tech/details/11868/) - [Gitコマンド一覧｜よく使う基本コマンドの早見表と用途別の使い方・トラブル対処【Git 2.56対応】](/tech/details/2787/) - [Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点](/tech/details/7018/) - [モノレポ（Monorepo）とは？マルチレポとの違い・メリット・デメリットと導入手順](/tech/details/3934/) --- 出典: [Git 2.52.0の新機能と変更点｜git last-modified・git repo・geometric保守とその後の修正]()（株式会社一創）