Git 3.0で変わること（予定）：既定のブランチ名・SHA-256など今のうちに確かめること

Git 3.0 は、2026年10月14日時点でまだ出ていません。最新の正式版は 2.56.0（2026年9月28日）で、3.0 がいつ出るかも、公式には決まっていません。

この記事は、Git を使い始めた人が「3.0 で何が変わるのか」「今のうちに何かしておくべきか」を知るための整理です。材料は、Git の公式の文書 BreakingChanges に書かれている「3.0 で変わる予定のこと」です。3.0 の話はすべて予定で、変わることがあります。 決まったことのように読まないでください。手元で流したコマンドの出力は、git 2.39.3（Apple Git-145・macOS）のものです。2.56.0 の動きは、公式の文書やソースを読んだ範囲で書きます。

この記事でわかること

Git 3.0 は2026年10月14日時点で出ておらず、日付も決まっていないこと（最新の正式版は 2.56.0）
3.0 で変わる予定の主なこと: 新しいリポジトリの既定のブランチ名が main に、既定のハッシュが SHA-256 に、など
変わるのは「新しいリポジトリ」の話で、今あるリポジトリのブランチ名は変わらないこと
3.0 でなくなる予定のものと、なくならない予定の git checkout
今の Git で先に確かめられること（init.defaultBranch など）と、古い Git では設定が黙って無視される注意

Git 3.0 はいつ出る？（まだ出ていません）と BreakingChanges とは
1. Git の「互換を壊す版」とは
2. BreakingChanges とは
新しいリポジトリの既定のブランチ名は main になる？
1. 変わるのは「新しいリポジトリ」だけ
2. 今のうちに main にそろえる方法
ハッシュは SHA-1 から SHA-256 に変わる？今の SHA-1 のリポジトリはどうなる？
bare リポジトリを勝手に使わなくなる？（safe.bareRepository）
1. なぜ変えるのか
2. 今のまま使いたいとき・先に守りたいとき
ブランチやタグの記録のしかたが reftable に変わる？
Git 3.0 で Rust が必要になる？（ビルドする人向けの話）
1. 3.0 の前の版は長期サポート（LTS）に
3.0 でなくなるもの・なくならないもの（git checkout は残る）
1. git checkout は3.0 でもなくならない予定
今の Git で先に確かめるには？（設定の表と注意）
よくある質問
まとめ
参考資料

Git 3.0 はいつ出る？（まだ出ていません）と BreakingChanges とは

2026年10月14日時点の最新の正式版は、Git 2.56.0 です。公式サイト（git-scm.com）には 2.56.0 が 2026年9月28日の版として載っていて、配布の一覧（kernel.org）でも 2.56.0 が最新です。Git の開発の場所（git/git のタグ）に、3.0 や次の 2.57 のタグは、この日はありませんでした。

3.0 の日付については、公式の文書に次のように書かれています。

There is no planned release date for this breaking version yet.

つまり「この互換を壊す版の予定日は、まだ決まっていない」という意味です（BreakingChanges の Git 3.0 の節）。この記事では、「来年」のような時期は書きません。

Git の「互換を壊す版」とは

互換を壊す版（breaking release）とは、これまでの使い方や設定がそのままでは動かなくなりうる変更を入れる版のことです。公式の文書によると、そうした版は数年に1回で、これまでの例は Git 1.6.0（2008年8月）と Git 2.0（2014年5月）です。Git は 2.0 から「メジャー番号.マイナー番号」の形で番号を付けていて、次に互換を壊す版でメジャー番号を上げる計画です。つまり、互換を壊す次の版が 3.0 になります（BreakingChanges）。

ふだんの 2.x の版は、セキュリティの問題のような強い理由が無い限り、互換を壊さないことになっています。

BreakingChanges とは

BreakingChanges は、Git の次の互換を壊す版に向けて、「やめる予定のもの」と「やめないと決めたもの」の両方を記録している、Git の公式の文書です（題は "Upcoming breaking changes"）。変わるものは、長く続いた既定値の変更、もっとよい設計に置き換わったもの、直せないので代わりなしで消すもの、の3種類です。文書は「Changes（変わるもの）」「Removals（なくなるもの）」「なくさないもの」の節に分かれています。

読むときの注意が2つあります。

3.0 に載るのは「準備ができた」変更だけで、欲しいものの一覧ではない、と文書に書かれています
文書自身が「生きた文書」と名乗っていて、状況が変われば、前に決めた変更を見直すことがあると書いています

予定は変わりうる、という前提で読んでください。

新しいリポジトリの既定のブランチ名は main になる？

BreakingChanges には、3.0 で「新しいリポジトリの既定のブランチ名が main になる」と書かれています（Changes の節）。ブランチ名は、git init で作ったリポジトリの最初のブランチにつく名前のことです。今の Git の既定は master です。git init の文書にも「今は master で、Git 3.0 が出たら main に変わる」と書かれています（git init の文書）。

main にする理由は、大きな Git のホスティングサービスの多くが、新しいリポジトリでこの名前を使っているのに合わせるためだと書かれています。Git は、2020年12月11日のコミットから「既定の名前が変わる」という警告を出してきました。GitHub では、新しく作るリポジトリの既定のブランチ名がもう main です（GitHub の文書。GitHub の使い方はプルリクエストの記事でも説明しています）。

変わるのは「新しいリポジトリ」だけ

大事なのは、変わるのが新しいリポジトリだけだという点です。BreakingChanges の原文は "In new repositories, the default branch name will be main." で、既にあるリポジトリのブランチ名を書き換えるとは書かれていません。

手元の git 2.39.3 で確かめた結果は次のとおりです。init.defaultBranch を main にしたあとで、master のリポジトリを clone しても、ブランチ名は master のままでした。clone は、元のリポジトリのブランチ名を引き継ぎます。元のリポジトリも master のままでした。

$ git config --global init.defaultBranch main
$ git clone -q r06src r06clone && git -C r06clone branch --show-current
master
$ git -C r06src branch --show-current
master

（r06src は、ブランチ名 master で作ったリポジトリです。git 2.39.3 の出力です。）

3.0 の Git で clone したときの動きは、3.0 が出ていないため確かめられません。文書は新しいリポジトリの話として書いている、というところまでが、この記事で言えることです。

今のうちに main にそろえる方法

設定をしていない git init は、今の Git では master で始まり、ヒントを出します。手元の git 2.39.3 では次のように出ました。

$ git init r02
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint: 	git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint: 	git branch -m <name>
Initialized empty Git repository in <scratch>/r02/.git/

（<scratch> は作業フォルダの場所を略した表記です。）2.56.0 のソース（refs.c）を読むと、上の2.39.3 のヒントにある "This default branch name is subject to change." の文は、"This default branch name will change to "main" in Git 3.0." という文になっています。この文になったのは 2.52.0 からです。2.56.0 は手元で流していないので、ソースを読んだ範囲の話です。

main で始めたいときの方法は2つあります。

毎回 main にする: git config --global init.defaultBranch main を1回実行します。以後、git init で作るリポジトリは main で始まり、ヒントも出ません（git 2.39.3 で確認）。この設定は Git 2.28.0 から使えます
1回だけ main にする: git init -b main（--initial-branch=main でも同じ）

$ git init -b main r04
Initialized empty Git repository in <scratch>/r04/.git/
$ git -C r04 branch --show-current
main

作ったあとのリポジトリのブランチ名は、git branch -m <新しい名前> で変えられます。コミットが1つあるリポジトリで、master を main に変えた結果は次のとおりです（git 2.39.3）。

$ git branch --show-current
master
$ git branch -m main
$ git branch --show-current
main

git branch -m が変えるのは手元のブランチの名前です。今ある master のリポジトリを、3.0 に合わせて必ず main に変えなければいけない、とは BreakingChanges に書かれていません。

git worktree の記事の例（git worktree add -b emergency-fix ../temp master）では、master を自分のリポジトリのブランチ名に読み替えるよう書いています。既定のブランチ名は、リポジトリによって master のことも main のこともあるためです。

ハッシュは SHA-1 から SHA-256 に変わる？今の SHA-1 のリポジトリはどうなる？

BreakingChanges には、3.0 で「新しいリポジトリの既定のハッシュ関数が、sha1 から sha256 に変わる」と書かれています（Changes の節）。ハッシュ関数とは、コミットなどに付く名前（ハッシュ）を作る計算のことです。コミットの名前は、git log に出る英数字の羅列です（Git コマンドの記事でも説明しています）。

変える理由

文書によると、SHA-1 は NIST（アメリカの標準を決める機関）が2011年に非推奨にしていて、FIPS 140-2 などの認証でも勧められていません。また、SHA-1 の強さを弱める現実的な攻撃（practical attacks）が見つかっています。文書は、攻撃の例として SHAppening（2015年）・SHAttered（2017年）・Birthday-Near-Collision（2019年）・Shambles（2020年）を挙げています。

Git は既知の攻撃への守りを入れていますが、これからの研究でさらに攻撃が見つかると見込んでいて、備えとして新しいリポジトリの既定を変える、という説明です。変えるための前提は、よく使われる Git のライブラリ・アプリ・ホスティングサービスが SHA-256 に対応することだと書かれています。各サービスが対応済みかどうかは、この記事では確かめていません。

SHA-1 はなくならない・今は互いにやりとりできない

次の2点は、先に知っておいてください。

SHA-1 をやめる計画は、今のところありません。 文書には "There is no plan to deprecate the "sha1" object format at this point in time." とあります。既にある SHA-1 のリポジトリが使えなくなる、とは書かれていません
今は、SHA-256 のリポジトリと SHA-1 のリポジトリの間で、やりとりができません。 git init の文書に "At present, there is no interoperability between SHA-256 repositories and SHA-1 repositories." とあります

手元の git 2.39.3 では、SHA-1 のリポジトリの中から SHA-256 のリポジトリを fetch すると、次のように止まりました。

$ git fetch ../sha256-repo
fatal: mismatched algorithms: client sha1; server sha256

（SHA-256 のリポジトリを clone した場合は、できた側も SHA-256 になりました。）ですので、「今のうちに SHA-256 を既定にしておく」という準備はおすすめできません。SHA-1 のリポジトリを使っている相手や、SHA-256 に対応していない道具とのやりとりに困るおそれがあるためです。

SHA-256 のリポジトリを作ると、見た目はどう違う？

今の Git でも、git init --object-format=sha256 で SHA-256 のリポジトリを作れます。既定は sha1 です。練習用のリポジトリで作ると、違いが分かります。手元の git 2.39.3 では次のとおりでした。

$ git init -q -b main --object-format=sha256 practice
$ cd practice
$ git rev-parse --show-object-format
sha256
$ echo a > a.txt; git add a.txt; git commit -q -m first
$ git rev-parse HEAD
4f434403833c71b6aeaee26d34f3e6855822179ac7cbd4b4347ccc55f362cdd7
$ git log --oneline
4f43440 first

コミットの名前は64文字でした。同じ手順で、オプションなし（SHA-1）で作ったときは40文字でした。git log --oneline の短い表示は、どちらも7文字でした。ハッシュの値は、中身・名前・日時で変わります。上の値は例です。

なお、以前は「SHA-256 のリポジトリは、あとで互換のない変更が要るかもしれない」と警告していましたが、git init の文書（2.56.0 の版）は、今は互換のある変更だけを見込んでいると書いています。今の Git で作った SHA-256 のリポジトリは、将来の Git でもデータを失わずに使える見込みだ、とも書かれています。

bare リポジトリを勝手に使わなくなる？（safe.bareRepository）

BreakingChanges には、設定 safe.bareRepository の既定が all から explicit に変わる、と書かれています（Changes の節）。

bare リポジトリとは、ふつうは名前の最後が .git のフォルダで、ファイルを取り出した作業用のコピー（作業ツリー）を持たないリポジトリのことです。ふだんは隠れた .git フォルダの中にある管理用のファイルが、そのフォルダの直下に置かれています（Git 用語集）。

なぜ変えるのか

文書が挙げる理由は、攻撃の防止です。悪意のある「フック」（Git が自動で動かすスクリプト）を仕込んだ bare リポジトリを中に入れたリポジトリを clone させ、そのフォルダの中で Git のコマンドを動かすと、フックが動いてしまうことがあります。シェルのプロンプトが裏で git status を流す設定だと、cd で入っただけで危なくなることもある、と書かれています。

explicit になると、フォルダをさかのぼって見つけた bare リポジトリでは、Git が動かなくなります。--git-dir で指定したものや、環境変数 GIT_DIR で指定したものは、これまでどおり動きます。ふつうの .git のあるリポジトリ、worktree、サブモジュールには影響しません。

手元の git 2.39.3 で、bare リポジトリの中で試した結果は次のとおりです（フォルダの場所は書き換えています）。

$ git config --global safe.bareRepository explicit
$ git status
fatal: cannot use bare repository '/path/to/inner.git' (safe.bareRepository is 'explicit')
$ git --git-dir=. rev-parse --is-bare-repository
true

ふつうのリポジトリの中の git status は、そのまま動きました。

今のまま使いたいとき・先に守りたいとき

今の動きのまま使いたい人は、全体（global）かシステムの設定に safe.bareRepository=all を書けば、3.0 で既定が変わったあとも前の動きにできる、と文書に書かれています
bare リポジトリを使わないなら、全体の設定に explicit を入れておくと、この攻撃から守れる、と git config の文書が勧めています（git config の文書）。この設定は Git 2.38.0 から使えます

この設定は、リポジトリの中の設定ファイル（.git/config）に書いても効きません。これは、信用できないリポジトリが値を書き換えるのを防ぐためです。

ブランチやタグの記録のしかたが reftable に変わる？

BreakingChanges には、新しいリポジトリでの「参照」の保存のしかたが、files から reftable に変わると書かれています。参照とは、ブランチやタグなどの名前のことです。reftable は、その名前をまとめて記録する新しい形式です。

文書が挙げる利点のうち、初心者に関係しそうなものを1つ紹介します。files の形式だと、大文字・小文字だけが違う2つのブランチ名を、大文字・小文字を区別しないファイルシステム（Windows や macOS でよくある）に置けません。reftable はファイルの名前に頼らずに参照の名前を記録するので、この問題が起きない、と書かれています。ほかの利点も、同じ節に書かれています。

前提として、JGit・libgit2・Gitoxide といった Git のほかの実装が reftable に対応する必要がある、と書かれています。各実装が対応済みかどうかは、この記事では確かめていません。

今の Git でも、git init --ref-format=reftable で reftable のリポジトリを作れます（--ref-format のオプションは 2.44.0 からありますが、値に reftable が使えるのは Git 2.45.0 からです）。手元の git 2.39.3 では使えず、error: unknown option で始まるエラーが出て止まりました（終了コードは 129）。

毎回の既定を変える設定は、2.56.0 では init.defaultRefFormat です（Git 2.47.0 から）。ただし、まだ出ていない次の版に向けた開発中の文書では、名前が init.defaultRefStorageFormat に変わっていて、init.defaultRefFormat は古い名前（非推奨の別名）になっています。オプションも、次の版では --ref-storage-format になり、--ref-format は非推奨の別名になる、と開発中の文書にあります。使う版の文書で、名前を確かめてください。

Git 3.0 で Rust が必要になる？（ビルドする人向けの話）

BreakingChanges には、3.0 で、Git をソースから作る（ビルドする）ときに Rust（プログラミング言語）が必須になる予定だと書かれています。Git は 2.49 から Rust を取り入れ始めましたが、今のところ Rust で書かれた部分はどれも任意です。

これは、Git を「作る」側の話です。Mac や Windows などで配られている Git を入れて使う人が、何かをする必要があるとは、文書に書かれていません。ソースからビルドする人や、Git を配る人に向けた変更と読むのが妥当です。

文書が書く段階は、次の3つです。

Git 2.52: Rust への対応を、Meson（ビルドの道具）では自動で判定し、Makefile では無効にして、土台を整える
Git 2.55: どちらのビルドの方法でも、Rust への対応が既定で有効になる。Rust が無い環境では、既定ではビルドが失敗するが、ビルドのフラグで外せる
Git 3.0: ビルドのフラグがなくなり、Rust が必須になる

注意点が2つあります。

影響が大きいと分かれば、3.0 での必須化を見送って、あとの版に回すことがある、と文書に書かれています。「3.0 で必ず必須になる」とは言えません
Rust を有効にするためのビルドの書き方が、文書と Makefile で違って見えます。BreakingChanges は make WITH_RUST=YesPlease と書いていますが、2.56.0 の Makefile を読むと、Rust を外すときの名前は NO_RUST です。ビルドするときは、使う版の Makefile の説明を確かめてください（手元でビルドはしていません）

3.0 の前の版は長期サポート（LTS）に

同じ項目に、Git の開発チームは 3.0 の直前の版を長期サポート（LTS）の版にする、とも書かれています。LTS の版は、大事なバグの修正を少なくとも4つの版の間、セキュリティの修正を6つの版の間受ける、と書かれています。どの版が LTS になるかは決まっていません。「直前の版」としか書かれていないためです。

3.0 でなくなるもの・なくならないもの（git checkout は残る）

BreakingChanges の Removals の節には、なくなる予定のものが並んでいます（Removals の節）。初心者がふだん使うものは少ないので、表で一覧にします。

なくなる予定のもの	文書の説明	代わり
`git whatchanged`	10年以上前に役目を終えたコマンド。今は `--i-still-use-this` を付けないと動かない、と書かれている	`git log --raw`
`git pack-redundant`	余分なパックファイルを消すコマンド。とても遅くて使い物にならないとされている	文書に代わりの記載なし
grafts（`info/grafts`）	古い、コミットのつなぎ方を変えるしくみ	`git replace`
`.git/branches/` と `.git/remotes/`	リモートの短い名前を置く古いしくみ	リポジトリの設定にリモートを書く
`git name-rev --stdin`	同じ意味の `--annotate-stdin` に置き換えられている	`--annotate-stdin`
設定 `core.commentString=auto`	非推奨	文書に代わりの記載なし
設定 `core.preferSymlinkRefs=true`	HEAD などをシンボリックリンクで書く設定。なくなるのは書く側だけで、読むのは当面できる	ふつうのファイルに文字で書く形（今の既定）

手元の git 2.39.3 では、git whatchanged は止まらずに動き、git log --raw と同じ形を出しました。git pack-redundant は、2.39.3 では 'git pack-redundant' is nominated for removal.（廃止の候補になっている）という注意が出ましたが、コマンドは動きました（パックのあるリポジトリで --all を付けた結果。終了コードは 0）。--i-still-use-this を付けないと止まるようになったのは Git 2.41.0 からだと、そのリリースノートに書かれています。git whatchanged に --i-still-use-this のオプションが入ったのは Git 2.51.0 からです。

git checkout は3.0 でもなくならない予定

「git checkout はなくなるのか」という疑問に対して、BreakingChanges には、なくならない予定のもの（"Superseded features that will not be deprecated" の節）として、次のように書かれています。git checkout の役目は、git switch（ブランチの切り替え）と git restore（ファイルを戻す）の2つで代わりがきくが、git checkout を使う人がまだ多いので、3つとも残る、という内容です。

ただし、続けて「どのコマンドもほとんど使われなくなったら、見直すかもしれない」とも書かれています。ずっと残ると決まった、という意味ではなく、3.0 の予定ではなくならない、という意味です。文書は、「代わりがあること」と「いずれ消えること」は同じではない、とも書いています。

git switch と git restore は、2.51.0 で「試験的」の扱いが外れました。git restore の使い方は、reset・revert・restore の記事で説明しています。

今の Git で先に確かめるには？（設定の表と注意）

3.0 の変更のうち、設定やオプションで先にそろえられるものがあります。ブランチ名・ハッシュ・参照の形式の3つは、新しく作るリポジトリにだけ効き、既にあるリポジトリは変わりません。safe.bareRepository は例外で、今ある bare リポジトリにもすぐ効きます（手元の git 2.39.3 では、設定の前に作った bare リポジトリで fatal: cannot use bare repository と出ました）。git whatchanged は、リポジトリを作る話ではなく、使うコマンドを替えるだけの話です。

最初に、自分の Git の版を確かめます。設定が効くかどうかは、版しだいだからです。

$ git --version
git version 2.39.3 (Apple Git-145)

（手元の Mac（macOS 14.4.1）の /usr/bin/git（Apple Git-145）の出力です。ほかの Mac で同じ版かどうかは確かめていません。Git の基本のコマンドはこちらの記事にまとめています。）

3.0 の変更（予定）	今の版で先にそろえる方法	要る版	手元（2.39.3）の結果
既定のブランチ名 `main`	`git config --global init.defaultBranch main`（毎回）／`git init -b main`（1回だけ）	2.28.0 から	効いた
既定のハッシュ SHA-256	`git init --object-format=sha256`（1回だけ）／`git config --global init.defaultObjectFormat sha256`（毎回）	オプションは 2.39.3 で使えた。設定は 2.47.0 から	オプションは効いた。設定は無視された
参照の形式 reftable	`git init --ref-format=reftable`（1回だけ）／`git config --global init.defaultRefFormat reftable`（毎回。2.56.0 の名前）	`--ref-format=reftable` は 2.45.0 から。設定は 2.47.0 から	オプションはエラー。設定は無視された
`safe.bareRepository` が `explicit` に	`git config --global safe.bareRepository explicit`	2.38.0 から	効いた
`git whatchanged` がなくなる	代わりの `git log --raw` を使う	──	`git log --raw` は動いた

古い Git では、設定が黙って無視される

見落としやすい点です。手元の git 2.39.3 では、init.defaultObjectFormat と init.defaultRefFormat を設定しても、エラーも警告も出ずに無視されました。git config --global で書いても、-c で渡しても、同じでした。たとえば、-c init.defaultObjectFormat=sha256 を付けて git init しても、できたのは sha1 のリポジトリでした。環境変数 GIT_DEFAULT_HASH=sha256 を付けた場合は、2.39.3 でも SHA-256 になりました。

設定したあとは、git rev-parse --show-object-format で、本当に効いたかを確かめてください。sha256 と出れば SHA-256 です。

どれを先にそろえるべきか

SHA-256 と reftable は、「試しに既定にする」ものではありません。SHA-256 のリポジトリは SHA-1 のリポジトリとやりとりできませんし（前の節のとおり）、reftable は Git のほかの実装の対応が前提だからです。この2つは、練習用のリポジトリで作ってみるだけにとどめ、--global の既定にしておくことは勧めません。

いちばん安全に今そろえられるのは、init.defaultBranch を main にすることです。名前だけの違いで、GitHub の新しいリポジトリも main だからです。

ビルドで 3.0 の動きをまとめて確かめる（Git を作る人向け）

BreakingChanges には、3.0 で入る変更はビルドのときのスイッチ WITH_BREAKING_CHANGES で切り替えられるように作る決まりだと書かれています。これを付けて作った Git は、文書も含めて、3.0 の変更がもう入ったかのように動きます。Git の開発では、この形で動かすテスト（CI）も回しています。ビルドの手順は、手元で確かめていないため、この記事には書きません。

利用者向けに「3.0 を先に試せる配布物」を公式が出している、という記述は、BreakingChanges などを見た範囲では見つかりませんでした。

よくある質問

Git 3.0 はいつ出ますか？

2026年10月14日時点で、決まっていません。公式の BreakingChanges に "There is no planned release date for this breaking version yet." と書かれています。最新の正式版は 2.56.0（2026年9月28日）です。互換を壊す版は数年に1回で、前の例は 2008年8月の Git 1.6.0 と、2014年5月の Git 2.0 です。この記事では、3.0 の時期は予想しません。

master と main の違いは何ですか？どちらを使えばよいですか？

Git の公式の文書が書いているのは、新しいリポジトリの既定の名前が master から main に変わる予定だ、ということです。main にする理由は、大きな Git のホスティングサービスの多くが新しいリポジトリでこの名前を使っているのに合わせるため、と書かれています。名前以外の動きの違いは、見た範囲の公式の文書には書かれていませんでした。GitHub で新しく作るリポジトリの既定のブランチ名は、もう main です。

今ある master のリポジトリも main に変えないといけませんか？

BreakingChanges が書いているのは「新しいリポジトリ」の話で、既にあるリポジトリのブランチ名を変える必要があるとは書かれていません。手元の git 2.39.3 では、init.defaultBranch を main にしても、master のリポジトリを clone すると master のままでした。手元のリポジトリのブランチ名を変えたいなら、git branch -m main が使えます。GitHub など、リモート側の既定のブランチの変え方は、この記事では扱いません。

Git 3.0 では Rust が必要ですか？

ソースから Git を作る（ビルドする）ときに、Rust が必須になる予定です。Mac や Windows などで配られている Git を入れて使うだけの人が、何かをする必要があるとは、文書に書かれていません。影響が大きければ、必須化を後の版に回すこともある、と文書にあります。

SHA-256 にしないといけませんか？今の SHA-1 のリポジトリは使えなくなりますか？

変わる予定なのは、新しいリポジトリの既定です。BreakingChanges は、SHA-1 をやめる計画は今のところないと書いています。今は SHA-256 と SHA-1 のリポジトリの間でやりとりできないので、必要がないのに今のうちに既定を SHA-256 にするのは勧めません。SHA-256 に対応しているホスティングサービスがどこかは、この記事では確かめていません。

まとめ

Git 3.0 は、2026年10月14日時点でまだ出ておらず、日付も決まっていません（最新の正式版は 2.56.0）。この記事の 3.0 の話は、すべて公式の文書 BreakingChanges に書かれた予定です
新しいリポジトリの既定のブランチ名は、main に変わる予定です。今あるリポジトリの名前は変わりません（文書は新しいリポジトリの話として書いています）。2.39.3 では、設定を変えても clone は元の名前のままでした。今そろえるなら git config --global init.defaultBranch main です
新しいリポジトリの既定のハッシュは SHA-256 に変わる予定ですが、SHA-1 をやめる計画はなく、SHA-256 と SHA-1 の間では今やりとりできません
safe.bareRepository の既定が explicit に、参照の形式が reftable に、ビルドで Rust が必須に、という変更も書かれています（Rust は後の版に回ることもあります）
git checkout は3.0 でもなくならない予定です。git whatchanged などはなくなる予定です
古い Git では、init.defaultObjectFormat などの設定が黙って無視されます。設定したあとは、効いたかを確かめてください