Gitの最新バージョンは2.56.0で、2026年9月28日にタグが打たれました。手元の版はgit --versionで確認できます。2.56.0の新機能を使いたいなら、表示がそれより小さい環境は更新の対象です。ただし入手経路によって届く版が違い、2026年10月18日時点でHomebrewは2.56.0、wingetとUbuntuのgit-core PPAはまだ2.55系です。この記事では、確認方法とOS別の更新手順、2.56で増えたコマンド、そして次のメジャー版Git 3.0の予定を、Gitのソースに同梱された公式文書と、v2.56.0を実際にビルドして試した結果で整理します。
まとめ:Gitの最新バージョンと確認・更新の要点
- 最新安定版:Git 2.56.0(2026年9月28日)。Windows向けの最新はGit for Windows 2.56.0.windows.2(2026年10月5日)。
- 確認:
git --version。macOS標準のApple Git-155は2.50.1ベースで、最新版より6リリース古い。 - 更新:macOSは
brew upgrade git、Windowsはgit update-git-for-windows、Ubuntuはgit-core PPA。Ubuntu 24.04の標準パッケージは2.43.0のまま。 - Git 3.0:公式文書は「予定日はまだない」と明記。次のリリースは2.57ではなく2.98で、3.0へ向けた準備版と位置づけられている。
- 3.0で変わる既定:初期ブランチ名がmain、参照の格納形式がreftable、ハッシュがSHA-256、ソースからのビルドにRustが必須、埋め込みベアリポジトリの自動検出を拒否。
Gitの最新バージョンとリリース履歴
Gitはおおむね10〜13週ごとにマイナー版を出しています。直近5回のタグ日付は次のとおりで、2.52から2.56までの間隔は77日・77日・70日・91日でした。日付はgit/gitリポジトリのタグに記録された日(UTC)です。
| 版 | タグ日付 | 代表的な変更 |
|---|---|---|
| 2.56.0 | 2026-09-28 | branch --delete-merged・add --resolved |
| 2.55.0 | 2026-06-29 | フック並列実行 / Rustを既定で有効化 |
| 2.54.0 | 2026-04-20 | git history / 設定ファイルでフック定義 |
| 2.53.0 | 2026-02-02 | maintenance is-needed・blame --diff-algorithm |
| 2.52.0 | 2025-11-17 | git last-modified / git repo / git refs list |
2.52の新コマンドはGit 2.52の新機能と変更点で個別に解説しています。2.56.0の全変更は公式リリースノート(RelNotes 2.56.0)にあります。
版番号の読み方:2.56.0・2.51.2・2.55.0.windows.5
Git本体の版はメジャー.マイナー.パッチの3桁です。2.56.0のマイナー番号が上がる版で新機能が入り、2.51.1や2.51.2のようにパッチ番号が上がる版は不具合やセキュリティの修正だけを含みます。2.52.0から2.56.0の間には本体のパッチ版のタグは打たれていません。
4桁目が付く2.55.0.windows.5や2.55.0.5は、Git for Windowsが同じ本体版を作り直した回数です。git version 2.55.0.windows.5と表示されたら「本体は2.55.0、Windows版としては5回目のビルド」という意味で、本体の2.55.5があるわけではありません。wingetのパッケージ一覧ではこれが2.55.0.5と表記されます。
インストール済みGitのバージョン確認コマンドと表示の読み方
Windowsのコマンドプロンプト・PowerShell、macOS・Linuxのターミナルのどれでも、次の1行で確認できます。
git --version
git version 2.56.0のように表示されます。git version(ハイフンなし)でも同じ結果です。ビルド時の構成まで見たい場合は--build-optionsを付けます。v2.56.0をソースからビルドした環境での出力から主要項目を抜粋すると次のとおりで、Rust対応の有無と既定のハッシュ方式がわかります。
$ git version --build-options
git version 2.56.0
cpu: x86_64
rust: enabled
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
Windowsの「2.55.0.windows.5」表示の意味と更新の目安
Git for Windowsでは末尾に.windows.Nが付きます。2026年10月18日時点の最新はGit for Windowsの2.56.0.windows.2なので、2.55.0.windows.5以前なら更新の対象です。インストーラーの選択肢やwingetの遅れなどWindows固有の事情はGit for Windowsの最新版と更新方法にまとめています。
macOSの「Apple Git-155」表示の正体とHomebrew版への切り替え
Xcodeコマンドラインツールに入っているApple製のGitです。macOS 26.6.2・Command Line Tools 26.6の環境では次の表示になりました。
$ /usr/bin/git --version
git version 2.50.1 (Apple Git-155)
ベースは2025年に出た2.50.1で、2.56.0までの新コマンドは使えません。たとえば後述のgit branch --delete-mergedを実行するとerror: unknown option `delete-merged'で止まります。Apple Gitはコマンドラインツールの更新でしか版が上がらないため、最新版が必要ならHomebrewで別に入れます。
OS別のGitアップデート手順と配布元ごとの届く版
Gitの更新は上書きインストールで済み、リポジトリの履歴や~/.gitconfigの設定は残ります。注意したいのは、入手経路によって届いている版がばらばらな点です。2026年10月18日に各配布元のAPIで確認した版は次のとおりです。
| 入手経路 | 届く版 | 確認元 |
|---|---|---|
| Homebrew(macOS・Linux) | 2.56.0 | formulae.brew.sh |
| Git for Windows インストーラー | 2.56.0.windows.2 | gitforwindows.org |
| winget(Git.Git) | 2.55.0.5 | winget-pkgs |
| Ubuntu git-core PPA | 2.55.0 | Launchpad |
| Ubuntu 26.04 標準 | 2.53.0 | Launchpad |
| Ubuntu 24.04 標準 | 2.43.0 | Launchpad |
| Ubuntu 22.04 標準 | 2.34.1 | Launchpad |
| Debian 13 標準 | 2.47.3 | sources.debian.org |
| Debian 12 標準 | 2.39.5 | sources.debian.org |
| macOS 標準(CLT 26.6) | 2.50.1 | 実機のgit --version |
Ubuntuの安定版の標準パッケージは、リリース時点の版を据え置いたまま、セキュリティ修正や重要な不具合修正を取り込むのが基本です。Ubuntu 24.04でapt upgradeを何度実行しても2.43系のままなのはこのためで、版番号が古くても修正は入っています。
Windows:Git for Windowsの更新コマンドとwingetの遅れ
Git for Windowsを導入済みなら、付属のコマンドで最新のインストーラーを取得して更新できます。
git update-git-for-windows
winget upgrade --id Git.Git -eでも更新できますが、上の表のとおりwingetは2.55.0.5で止まっています。2.56系が必要なら公式サイトのインストーラーかgit update-git-for-windowsを使います。
macOS:Homebrewでの更新とPATHの優先順位
brew update
brew upgrade git
未導入ならbrew install gitです。更新後もgit --versionがApple Gitのままなら、Homebrew版よりApple Gitが優先されている可能性があります。which -a gitで候補を並べ、Homebrew版(Apple Siliconは/opt/homebrew/bin/git、Intelは/usr/local/bin/git)が先に出るよう~/.zshrcのPATHを直し、exec $SHELL -lでシェルを読み直します。
Linux:Ubuntu・Debian・Fedoraのディストリビューション別の更新経路
Ubuntuで標準より新しい版が必要なら、Gitのメンテナー陣が提供するgit-core PPAを追加します。2026年10月18日時点でPPAの最新は2.55.0で、2.56.0はまだ届いていません。
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git
DebianにはPPAが無いため、新しい版が必要ならHomebrew on Linuxかソースからのビルドになります。Fedoraはsudo dnf upgrade git、Archはsudo pacman -Syu gitで各ディストリビューションの最新パッケージに上がります。
Git 2.56の新機能(2026年9月)
2.56.0では、日常の後片付けに効くオプションが2つ増えました。どちらもv2.56.0をビルドして動作を確かめています。
git branchのdelete-mergedオプションによる取り込み済みブランチの一括削除
git branch --delete-merged <upstream>は、追跡先(upstream)に作業が取り込み済みのローカルブランチを消します。origin/mainを追跡するトピックブランチを2本作り、片方だけをmainへ取り込んでpushした状態で実行した結果です。
$ git branch -vv
* main 1989919 [origin/main] add topic a
topic-a 1989919 [origin/main] add topic a
topic-b 3c21ef3 [origin/main: ahead 1, behind 1] add topic b
$ git branch --dry-run --delete-merged origin/main
Would delete branch topic-a (was 1989919).
$ git branch --delete-merged origin/main
Deleted branch topic-a (was 1989919).
未取り込みのtopic-bは黙って残ります。注意点は、origin/feat-xのような同名のリモートブランチを追跡しているだけのブランチは消えないことです。git branchの公式ドキュメントは、pushすると追跡先が更新される関係のブランチを「pull直後と区別できない」として削除対象から外すと説明しています。PRごとに同名のリモートブランチへpushし、それを追跡している構成では削除されません。トピックブランチの追跡先を統合先のブランチ(mainなど)にしている運用で効きます。
git addのresolvedオプションによる競合解決済みパスだけのステージ
git add --resolvedは、コンフリクト中のパスのうち解決が済んだものだけをステージし、無関係な作業中の変更は触りません。競合マーカーが残っていると止まります。
$ git add --resolved
fatal: the following paths still have conflict markers:
a
$ (aを編集して解決)
$ git add --resolved
$ git status --short
M a
M u.txt
競合とは別に編集していたu.txtは未ステージのまま残りました。git add .で作業中の変更まで巻き込む事故を防げます。
git history drop・git refsの新サブコマンド・ヘルプの終了コード変更
- 実験的な
git historyにdropが追加され、指定コミットを消して子孫を付け替えられる(git rebaseの対話モードで行っていた操作の一部)。 git refsにcreate・delete・update・renameが追加。-hでヘルプを出したときの終了コードが129から0に変更。Apple Git 2.50.1のgit branch -hは129、2.56.0は0を返した。ヘルプ表示の終了コードで分岐するスクリプトは見直しが要る。git bisectに--reset-when-found、git replayに--linearizeが追加。
2.53〜2.55で入った主な変更
2.52以前から上げる場合は、この3版の変更もまとめて入ります。
2.55:設定ファイルで定義したフックの並列実行と効かないフック
2.54からhook.<名前>.commandとhook.<名前>.eventでフックを設定ファイルに書けるようになり、2.55でそれらを並列に走らせられるようになりました。条件は公式ドキュメントにあり、すべてのフックにparallel = trueを付けたうえでhook.jobsを2以上にする必要があります(既定は1)。2秒かかるフックを2本登録したpre-pushで測ると、次の差になりました。
git config hook.lint.command "sleep 2; echo lint done"
git config hook.lint.event pre-push
git config hook.test.command "sleep 2; echo test done"
git config hook.test.event pre-push
git config hook.lint.parallel true
git config hook.test.parallel true
git config hook.jobs 2
| 設定 | pushの所要時間 |
|---|---|
| parallel・jobsとも未設定 | 4秒 |
| parallel=trueのみ(jobs未設定) | 4秒 |
| parallel=true+hook.jobs=2 | 2秒 |
pre-commitは並列化できません。公式ドキュメントはpre-commit・commit-msg・post-checkoutなどを作業ツリーやインデックスを共有するため常に逐次実行するフックとして挙げており、同じ設定をpre-commitに入れても4秒のままでした。リンターとテストを並列にしたいなら、pre-commitではなくpre-pushに置きます。2.55ではgit historyにfixupも加わりました。
2.54・2.53:git historyの追加と保守方式の既定変更
2.54では実験的な履歴編集コマンドgit historyが追加され、reword(コミットメッセージの修正)とsplit(1コミットの分割)を使えます。git maintenanceの既定方式はgeometricへ変わり、ASCII英数字以外の文字を含むエイリアス名も書けるようになりました。2.53では、保守が必要かを判定するgit maintenance is-neededと、git blame --diff-algorithmが追加されています。
ソースからのビルドでRustが既定有効になった2.55以降の対処
2.55から、Makefile・Meson ともにRust対応が既定で有効です。ソースからGitをビルドしているCIやDockerfileは、Rustのツールチェーンが無いと止まります。v2.56.0のソースで、PATHからcargoを外してmakeした結果です。
AR libgit.a
CARGO target/release/libgitcore.a
/bin/sh: cargo: command not found
make: *** [target/release/libgitcore.a] Error 127
今はまだ無効化できます。Makefileならmake NO_RUST=YesPlease、Mesonなら-Drust=disabledです。NO_RUST=YesPleaseでビルドし直すと通り、git version --build-optionsはrust: disabledを返しました。ただしMakefileのコメントには「With Git 3.0 though, Rust will always be enabled.」とあり、3.0では無効化の設定を削除してRustを必須にする予定です。BreakingChangesは、ディストリビューションへの影響が大きければ必須化を後の版へ延ばす可能性も併記しています。rustc 1.98.0を入れた環境ではそのまま通りました。
パッケージで入れているだけの利用者には関係ありません。影響を受けるのは、自社のビルドパイプラインでGitをソースからビルドしている場合です。そうした基盤の棚卸しはDevOps・CI/CD導入支援でも対応しています。
Git 3.0の公開予定と既定値の変更点
Git 3.0の公開日は決まっていません。v2.56.0に同梱されたBreakingChangesは「There is no planned release date for this breaking version yet.」と書いています。2025年10月には、Gitの開発者会議で2026年末までの公開を目指す話が出たとPhoronixが報じましたが、公式の日程ではありません。
手がかりは開発ブランチにあります。2.56.0の2日後、2026年9月30日に「Start Git 2.98 cycle」というコミット(c46c1e3)が入り、次のリリースは2.57ではなく2.98になりました。2.98.0のリリースノート(開発中)の冒頭は「This is meant to be the antepenultimate release to prepare for the long anticipated Git 3.0」で、2.98を3.0の最後から3番目の準備版と位置づけています。開発中の文書なので計画は変わりえますが、3.0の前に少なくとも2.98とその次の版が出る見込みです。BreakingChangesは、3.0直前の版を長期サポート版(重要なバグ修正は4リリースサイクル以上、セキュリティ修正は6サイクル)にするとも定めています。
| 項目 | 2.56.0の既定 | Git 3.0の予定 | 今から先取りする設定 |
|---|---|---|---|
| 初期ブランチ名 | master | main | init.defaultBranch=main |
| 参照の格納形式 | files | reftable | init.defaultRefFormat=reftable |
| 新規リポジトリのハッシュ | SHA-1 | SHA-256 | git init --object-format=sha256 |
| ビルド時のRust | 既定で有効(無効化可) | 必須 | rustcとcargoを用意 |
| safe.bareRepository | all | explicit | safe.bareRepository=explicit |
SHA-256への切り替えには前提条件があります。BreakingChangesは、主要なライブラリやホスティングサービスがSHA-256形式に対応していることを要件に挙げ、SHA-1形式を廃止する計画は無いとしています。
3.0相当のビルドで確かめた既定値の変化とSHA-1のまま残る点
Gitには、3.0で入る予定の変更を先に有効にするWITH_BREAKING_CHANGESというビルド設定があります。v2.56.0をこの設定でビルドし、空のディレクトリでgit initした結果を通常ビルドと比べました。
| 確認項目 | 通常ビルド | 3.0相当ビルド |
|---|---|---|
| symbolic-ref HEAD | refs/heads/master | refs/heads/main |
rev-parse --show-ref-format |
files | reftable |
rev-parse --show-object-format |
sha1 | sha1 |
| build-options の default-hash | sha1 | sha256 |
ブランチ名と参照形式は3.0の予定どおりに変わりましたが、作られたリポジトリのハッシュはsha1のままで、ビルド情報のdefault-hash: sha256という表示と一致しませんでした。v2.56.0のソースではgit initが既存設定を読む処理(setup.cのread_repository_format())で、設定ファイルが無い場合にハッシュをGIT_HASH_SHA1_LEGACYへ戻しています。3.0相当ビルドで新規リポジトリをSHA-256にしたいなら、v2.56.0の時点では--object-format=sha256の明示が必要です。
通常ビルドのgit initは、mainへの変更を予告する案内を出します。
hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0.
safe.bareRepositoryの変更は、作業ツリーの中に置かれたベアリポジトリへcdしたときに効きます。3.0相当ビルドでは次のように拒否され、--git-dir=.で明示すると動きました。
fatal: cannot use bare repository '/private/tmp/gitbuild/exp/outer/emb.git' (safe.bareRepository is 'explicit')
Git 3.0に備えて点検するCI・スクリプト・ベアリポジトリ
手元でGitを使うだけなら、3.0に合わせて急いで変えることはありません。ハッシュ方式・参照形式・初期ブランチ名の変更は新しく作るリポジトリが対象で、既存のSHA-1・filesのリポジトリはそのまま使えます。例外はsafe.bareRepositoryで、作業ツリー内に置いた既存のベアリポジトリにも効きます。先に手を打つべきなのは次の3つです。
- ソースからGitをビルドするCI:rustcとcargoを今のうちに入れる。2.55以降はRust無しだと既定で失敗する。
- masterを前提にしたスクリプト・手順書:
git init直後のブランチ名を決め打ちせず、git symbolic-ref --short HEADで取得するかinit.defaultBranchを明示する。ブランチ命名の決め方はGit運用のベストプラクティスを参照。 - ベアリポジトリを含むリポジトリを扱うツール:テスト用のフィクスチャなどで暗黙の検出に頼っているなら、
--git-dirかGIT_DIRで明示する形に直す。
逆に、SHA-256での新規リポジトリ作成を今から標準にするのは早いと考えます。BreakingChanges自身が対応を3.0の前提条件に置いているほど、ホスティングサービスやライブラリの対応がそろっていないためです。
よくある質問
現在のGitの最新バージョンはいくつですか?
2026年10月18日時点の最新安定版はGit 2.56.0(2026年9月28日)です。Windows版は2.56.0.windows.2です。次は2.98が開発中で、正確な最新版はgit-scm.comのダウンロードページでも確認できます。
コマンドプロンプトでGitのバージョンを確認する方法は?
コマンドプロンプトかPowerShellでgit --versionを実行します。git version 2.56.0.windows.2のように表示され、末尾の.windows.2はGit for Windowsのビルド番号です。
Gitのリリース日はいつですか?
Gitの最初の版は2005年に公開されました。現在のマイナー版は10〜13週おきで、直近は2.55.0が2026年6月29日、2.56.0が2026年9月28日です。
GitとGitHubの違いは何ですか?
Gitは手元で履歴を管理するバージョン管理ソフトウェアで、GitHubはGitのリポジトリをネット上で共有するホスティングサービスです。Gitの版はGitHubとは別に、Gitプロジェクトがリリースしています。
Git 3.0はいつ公開されますか?
公式の予定日はありません。開発中の2.98が3.0の最後から3番目の準備版とされているため、3.0は少なくとも2.98とその次の版の後になります。