Git 3.0 is planned for spring 2027 and flips three defaults for new repositories

Git’s maintainers plan to ship Git 3.0 in spring 2027, according to GitLab’s write-up of the Git Contributor Summit at Git Merge 2026 in Lisbon. New repositories will default to the SHA-256 hash, reftable reference storage and a first branch called main, per Git’s own BreakingChanges document. Repositories that already exist keep the format they have.

The schedule is a jump from the current Git 2.56 to Git 2.98 in December 2026, a version number chosen to tell distributors a big change is close. Git 2.99 and Git 3.0 then ship together in spring 2027, GitLab says. LWN reports April 2027 for that pair, citing Git developer Patrick Steinhardt at Kernel Recipes. Git 2.99 will be a long-term-support release, so platforms without a Rust toolchain keep getting updates, and 3.0 is the same code with the breaking changes switched on.

What changes in Git 3.0

Three of the changes apply only to repositories created after the upgrade. Two reach further: one changes how Git behaves in every repository, and one changes how you build Git itself.

Change	Git 2.x default	Git 3.0 default	Applies to	Try it today
Hash	sha1	sha256	New repositories	git init --object-format=sha256
Ref storage	files	reftable	New repositories	git init --ref-format=reftable
First branch	master	main	New repositories	git init -b main
Bare repositories	safe.bareRepository=all	explicit	Every repository	git config --global safe.bareRepository explicit
Rust	Optional	Required	Building Git from source	meson configure -Drust=enabled or make WITH_RUST=YesPlease

SHA-256. BreakingChanges says SHA-1 has been deprecated by NIST since 2011 and lists four published attacks on it, including SHAttered in 2017 and Shambles in 2020. It also says the project has no plan to deprecate the sha1 object format, so existing SHA-1 repositories keep working. A clone copies the format of the repository it comes from, so cloning an existing SHA-1 repository gives you SHA-1 whatever the default is.

Reftable. Git’s default stores each reference as a file under .git/refs, backed by a packed-refs file. Reftable is a binary format that, per the document, writes several references atomically, avoids clashes between names that differ only in case on Windows and macOS, and doesn’t rewrite all of packed-refs when a reference is deleted. Git lists JGit, libgit2 and Gitoxide as the implementations that need to support it first. LWN reports that Steinhardt added reftable support to libgit2 and turned SHA-256 on by default there in August.

Bare repositories. With safe.bareRepository set to explicit, Git only works with a bare repository named through --git-dir or the GIT_DIR environment variable. The document’s reason is that a cloned repository can contain an embedded bare repository with malicious hooks, and a shell prompt that runs git status can trigger them the moment you cd into it. On Git 2.43, a bare repository found by walking up the directory tree fails with fatal: cannot use bare repository ... (safe.bareRepository is 'explicit') when the setting is on. Setting it to all restores the old behaviour.

Rust. Git 2.52 added Rust detection to its Meson build, Git 2.55 enabled it by default in both build systems, and Git 3.0 removes the build options so Rust is mandatory. BreakingChanges adds that the project will check the effect on downstream distributions first, and may move the Rust requirement to a later minor release if the effect is large.

The document also lists removals for 3.0: grafts (replaced by git replace), git pack-redundant, git whatchanged (use git log --raw), git name-rev --stdin (use --annotate-stdin), remote shorthands in .git/branches and .git/remotes, core.commentString=auto, and writing symbolic refs as symlinks through core.preferSymlinkRefs.

Where GitHub stands on SHA-256

Git lists forge support as a condition for the SHA-256 default. LWN reports that GitLab has supported SHA-256 since 2024 and Forgejo supports it too, and calls GitHub “the elephant that is still missing from this room”. GitLab says GitHub announced a private beta at Git Merge, with general availability in a few months. LWN adds that brian m. carlson, a GitHub employee and a lead developer of the SHA-256 work, told the Git list news on that front was coming.

Until the beta opens up, repositories you host on GitHub need SHA-1, so set the object format explicitly once 3.0 changes the default.

A CI checklist before the upgrade

Each row below follows from a change in the table above.

Check	Why it breaks	Fix
Hash length	A SHA-256 object ID is 64 hex characters, not 40, so patterns like [0-9a-f]{40} reject it.	Accept both lengths, and read the format with git rev-parse --show-object-format.
Direct reads of .git/refs	Reftable keeps references in a binary format, not one file per reference.	Use git for-each-ref, git rev-parse and git symbolic-ref.
Branch name	Provisioning that assumes master gets main in a fresh repository.	Pass git init -b or set init.defaultBranch in your images.
Bare repositories	Git stops finding a bare repository by walking up the tree.	Use --git-dir or GIT_DIR, or set safe.bareRepository=all.
Hosting	A new repository that defaults to SHA-256 isn’t one GitHub hosts yet.	Set the hash explicitly for repositories you host there.
Building Git	Source builds need a Rust toolchain from 3.0.	Add Rust to build images, or stay on the 2.99 long-term-support release.
Removed commands	whatchanged, pack-redundant and the other removals stop working.	Search scripts for them and switch to the listed replacements.

To pin the current defaults in an image, set them once in global configuration:

git config --global init.defaultObjectFormat sha1
git config --global init.defaultBranch main
git config --global safe.bareRepository all

BreakingChanges says every change is guarded by a compile-time switch, WITH_BREAKING_CHANGES, and that the Git project runs a CI job on a build with it turned on. You can build Git that way to try your own pipeline before the release.

BreakingChanges still says no release date is planned for Git 3.0; the spring 2027 schedule comes from the contributor summit. GitHub hasn’t announced when SHA-256 repositories reach general availability. The next checkpoint is Git 2.98, planned for December 2026.