【Git】Git 3.0完全ガイド2026 — SHA-256デフォルト化・Reftable・Rust必須化の変更点と移行準備

結論

Git 3.0（2026年後半リリース予定）は、SHA-256デフォルト化・Reftableバックエンド・Rust必須化という3本柱のメジャーアップデートです。今すぐ試せる準備コマンドを先にどうぞ。

# Reftable形式でリポジトリ作成（fetchが最大22倍高速に）
git init --ref-format=reftable myproject

# SHA-256形式でリポジトリ作成（Git 2.51+で可能）
git init --object-format=sha256 myproject-sha256

# switch/restoreでcheckoutを置き換える習慣を
git switch -c feature/new-branch
git restore --staged main.go

上記のコマンドはすでに Git 2.48〜2.51 で利用可能です。3.0が来る前に、今のうちに新形式に触れておくとスムーズですね。

Git 3.0で変わる3つの大きなこと

Git 2.0がリリースされたのは2014年。それから11年以上、メジャーバージョンは据え置きでした。2026年後半に予定されているGit 3.0は、バージョン番号以上の意味を持つアップデートです。SHA-1からSHA-256への移行、参照ストレージのReftable化、Rust必須化という3つの変更が根幹に関わってきます。

それぞれの変更が実際の開発にどう影響するのか、今から何を準備すべきなのかを具体的に解説します。

SHA-256デフォルト化 — ついにSHA-1からの移行が始まる

なぜSHA-256が必要なのか

Gitは誕生以来、オブジェクトの識別子にSHA-1ハッシュを使ってきました。SHA-1は2017年のSHAttered攻撃で現実的な衝突攻撃が実証され、2020年のShambles攻撃でさらに深刻な脆弱性が明らかになりました。NISTがSHA-1を正式に非推奨としたのは2011年ですから、ずいぶん長い付き合いだったと言えますね。

Git 3.0では、git initで作成する新規リポジトリのデフォルトハッシュがSHA-256になります。

エコシステムの現状

SHA-256対応状況はプラットフォームによってばらつきがあります。

• 対応済み： Git本体、Forgejo、Dulwich（Pythonライブラリ）
• 実験的対応： GitLab、go-git、libgit2
• 未対応： GitHub、Bitbucket

現時点でSHA-256リポジトリを作成してもGitHubにはプッシュできません。Git 3.0のリリースで各ホスティングサービスの対応が加速することが期待されています。SHA-1とSHA-256の相互運用モードも準備中なので、既存リポジトリが突然使えなくなることはありません。

SHA-256リポジトリの作り方

# SHA-256形式で初期化
git init --object-format=sha256 my-repo
cd my-repo
git rev-parse --show-object-format  # → "sha256" と表示されればOK

Reftable — 参照操作が最大22倍高速に

従来のfilesバックエンドの問題

Gitのブランチやタグ（参照）は、伝統的に1つの参照につき1つのファイルとしてディスクに保存されてきました（.git/refs/heads/ 以下）。この方式には以下の問題があります。

• 大規模リポジトリで遅い： 数千の参照があると、ファイルシステムの走査に時間がかかる
• 大文字小文字の衝突： Windows/macOSで feature/Login と feature/login が共存できない
• アトミック性の欠如： 参照の更新がアトミックではなく、競合状態が発生しうる

Reftableがもたらす改善

Reftableはこれらをバイナリ形式で解決します。参照数10,000のリポジトリでのベンチマーク結果は以下の通り。

• git fetch： 最大22倍高速化
• git push： 最大18倍高速化

CI/CDパイプラインのように1日に何百回もfetch/pushを繰り返す環境だと、このインパクトはかなり大きいですね。

# Reftable形式でリポジトリ作成
git init --ref-format=reftable myproject
cd myproject
git rev-parse --show-ref-format  # → "reftable" と表示されればOK

# 既存リポジトリの参照形式を確認
git rev-parse --show-ref-format

Rust必須化 — メモリ安全性への投資

Git 3.0で最も話題になっているのが、Rustをビルド必須要件にする判断です。2005年からC言語で書かれてきたGitが、メモリ安全言語への移行を始めます。

なぜRustなのか

• メモリ安全性： バッファオーバーフローやuse-after-freeといったC言語由来の問題を、コンパイル時に排除できる
• モダンなツールチェーン： Cargoやclippyによる開発体験の向上
• コントリビューションの敷居低下： メモリ管理に詳しくなくても安全なコードを書ける

まずMesonビルドシステムでRustモジュールのサポートを追加し、Git 3.0で必須化するという2段階計画です。Reftableバックエンドで先行してRust移植が試され、コードの保守性と信頼性で良い結果が出ています。主要プラットフォーム（Linux/macOS/Windows）ではRustツールチェーンは問題なく利用できるので、ほとんどの開発者には影響ありません。

破壊的変更と非推奨機能

Git 3.0ではいくつかのレガシー機能が削除されます。

• git-whatchanged： git log --raw に置き換え。最近のバージョンでは --i-still-use-this フラグが必要
• デフォルトブランチ名： master → main
• SHA-1デフォルト： 新規リポジトリはSHA-256がデフォルトに
• files参照バックエンド： 新規リポジトリはreftableがデフォルトに

git switch と git restore（Git 2.33で導入）は実験的ステータスを卒業し、git checkout に代わる標準コマンドとして推奨されます。

今すぐできる移行準備

以下の準備は今日から始められます。Git 3.0のリリースを待つ必要はありません。

1. Reftableを試す

mkdir test-reftable && cd test-reftable
git init --ref-format=reftable
git commit --allow-empty -m "first commit"
git switch -c feature/test
git switch main

2. SHA-256を試す

git init --object-format=sha256 test-sha256
cd test-sha256
echo "hello" > test.txt
git add test.txt
git commit -m "initial commit"
git log --oneline  # 64桁のハッシュになっていることを確認

3. switch/restoreを使い始める

# ブランチの作成と切り替え
git switch -c feature/new-feature

# ファイルの変更を取り消し
git restore main.go

# ステージングの解除
git restore --staged config.json

# 特定のコミットの状態に戻す
git restore --source=HEAD~2 src/app.ts

4. スクリプトやツールの確認

• SHA-1の40桁ハッシュに依存している処理がないか確認（SHA-256は64桁）
• git whatchanged を使っているスクリプトを git log --raw に置き換え
• CI/CDパイプラインでGitをソースからビルドしている場合、Rustツールチェーンが必要になる可能性を考慮

【広告】快適な開発環境を支えるドメイン取得

Git 3.0でCI/CDが高速化したら、デプロイ環境も整えたいところです。お名前.comなら独自ドメインの取得からサーバー設定までまとめて管理できます。

お名前.com でドメインを取得する

まとめ

11年ぶりのメジャーバージョンアップとなるGit 3.0。セキュリティ・パフォーマンス・保守性のそれぞれで着実な進歩があります。

既存のSHA-1リポジトリはGit 3.0でもそのまま動きます。一方でReftableのパフォーマンス改善やSHA-256のセキュリティ強化は、新しいプロジェクトから恩恵を受けられます。今のうちに試して、スムーズな移行に備えておきましょう。

【広告】ConoHa WINGなら開発環境からデプロイまでワンストップで構築できます。「いつもありがとう！！」

ConoHa WING の詳細を見る