Git 3.0 Takes Shape, and Most of It Already Works Today

What Was Decided

Git 3.0 is the first release since Git 2.0 in May 2014 that is allowed to break old habits on purpose. The Git project keeps a running list of those changes in its BreakingChanges document, and for a long time the list had no date attached. That changed in September 2026. At the Git Contributor Summit, held during Git Merge 2026 in Lisbon, the people who build Git worked out a proposed schedule. The exact month is not settled yet.

The jump from 2.56 straight to 2.98 is deliberate. It tells distributions and everyone who packages Git that the big change is close. Git 2.99 and 3.0 are meant to ship together with the same features, and the only difference is that 3.0 switches the breaking changes on. Git 2.99 will be a long-term support release, with important bug fixes for at least four release cycles and security fixes for six. In practice that means anyone who needs more time can stay on 2.99 well into 2028.

Two things keep this calm. Existing repositories are not converted to anything, so a repository you clone or push today keeps working the same way after the upgrade. And almost every change on the list already works in current Git, so you can try it on your own terms long before it becomes the default.

What Changes in Git 3.0

A handful of old features go away. git whatchanged is replaced by git log --raw, grafts by git replace and the --stdin option of git name-rev by --annotate-stdin. git pack-redundant is removed, and so is support for remotes stored in the .git/branches and .git/remotes directories. Each of these has warned for years, and git whatchanged already refuses to run without an extra flag.

Why SHA-256 Now

When Linus Torvalds wrote Git in 2005, he identified every object by its SHA-1 hash. Researchers have since shown practical attacks on SHA-1, most famously SHAttered in 2017, when Google and CWI Amsterdam produced two different PDF files with the same hash. Git added protections against the known attacks, and nothing in this change is an emergency. The point is to move before the algorithm wears out further. NIST plans to phase SHA-1 out entirely by December 31, 2030, and the Git project wants new repositories on SHA-256 well before then.

SHA-256 support in Git is not new. It has existed for years, and Git 2.42 in August 2023 toned down the warning that called it an experimental curiosity, because the project no longer planned breaking changes to the format. The visible difference is the length of the IDs, 64 hexadecimal characters for each commit in place of 40.

The switch only affects repositories created after the upgrade. Git has no plan to deprecate SHA-1. A SHA-1 repository and a SHA-256 repository cannot yet push to or fetch from each other, which is why the change applies to new repositories only and why a migration tool is part of the planned work on the Rust side of Git.

Reftable, the Quiet Improvement

Every branch and tag in a classic Git repository is a small file under .git/refs, plus one large packed-refs file. That design is simple and it shows its age. Two branches whose names differ only in capital letters cannot live side by side on macOS or Windows. Deleting a single ref rewrites the whole packed-refs file, which can be dozens of megabytes in a large repository. A push that updates several refs is not atomic on disk.

The reftable format stores refs in compact binary tables, deletes with small markers, and compacts itself after every write. Git's own documentation says that writing many refs at once is faster by orders of magnitude, and the format takes less space. Reftable arrived in Git 2.45 in April 2024, git refs migrate in 2.46 can convert an existing repository, and Git 2.56 made it faster in repositories with many deletions and hardened it against corrupted tables.

For most people this change is invisible. It matters to tools that read files under .git/refs directly instead of asking Git, and to libraries that implement Git themselves. The Git project names JGit, libgit2 and Gitoxide as implementations that need reftable support before the default changes.

The Other Three Changes

The default branch for new repositories becomes main. Git has printed a hint about this since late 2020, and GitHub and GitLab already create main for new repositories, so for most teams nothing moves.

safe.bareRepository changes from all to explicit. Today, if someone tricks you into cloning a repository that contains a bare repository with hooks, simply changing into that directory can run them, because shell prompts call git status in the background. In Git 3.0, Git refuses to use a bare repository it discovers by walking up the directory tree. A bare repository named with --git-dir or the GIT_DIR environment variable keeps working.

Rust becomes a required part of building Git. Since Git 2.55 the build already uses Rust by default, with a switch to turn it off, and 3.0 removes the switch. This matters to people who build Git from source or package it for unusual platforms. Users installing Git from a distribution will not notice it.

Where GitHub and GitLab Stand

The SHA-256 default depends on the rest of the ecosystem being ready, and the Git project says so in writing. Forges, libraries and tools have to handle SHA-256 repositories before new repositories start out that way.

At Git Merge 2026, Git contributor brian m. carlson announced that GitHub has SHA-256 repositories in private preview. They are not publicly available yet, so you cannot create one, and he said GitHub plans to ship the feature soon.

GitLab lets you create a SHA-256 project, under Experimental settings, behind a feature flag that is off by default. GitLab's documentation describes it as available for testing and not ready for production. The format is chosen when a project is created and cannot be changed later.

The practical advice follows from that. Keep repositories that live on GitHub on SHA-1 for now, and use SHA-256 for local experiments and for servers you control.

What This Means for Your Servers and Pipelines

Most teams will upgrade Git and notice nothing, because their existing repositories stay as they are. The places worth a look are scripts and CI jobs that make assumptions Git 3.0 changes.

• Scripts that expect a 40-character hash. A pattern like [0-9a-f]{40} will not match a SHA-256 commit ID. Ask Git with git rev-parse --show-object-format instead of guessing from the length.
• Scripts that expect master in a new repository. Set init.defaultBranch explicitly in CI images and provisioning scripts, to whichever name you use, so the result does not depend on the Git version.
• Tools that read .git/refs as files. Use git rev-parse, git for-each-ref or git show-ref, which work with both formats.
• Jobs that change into a bare repository and run Git there. A cron job that runs cd /srv/git/project.git and then git gc stops working under explicit mode, and so does git -C. Pass --git-dir or set GIT_DIR.
• Custom Git builds. Make sure the build image has a Rust toolchain, since 2.55 already needs one unless you switch it off.

The Git that servers already run decides what you can test today. These are the versions in each release's current packages.

On the older releases you can still test everything except reftable, and a developer laptop with a current Git from Homebrew or the Git for Windows installer covers the rest.

Good Things You Get Before 3.0

The road to 3.0 is not only about defaults. Git 2.56, the current release, already brings a few changes that make daily work easier.

• git history drop. The git history command, still marked experimental, edits past commits without a full interactive rebase. It could already reword, split and fix up a commit, and 2.56 adds drop, which removes a commit and replays everything after it onto its parent. A --dry-run option shows what would happen first.
• git branch --delete-merged. Cleans up local branches whose work has already landed on the upstream branch they track. It skips any branch that is checked out or whose upstream is gone, and --dry-run shows the list before anything is deleted.
• git refs create, delete, update and rename. Scripts that manage branches and tags can use one consistent command, alongside the migrate, verify and list subcommands it already had.
• Better git log --follow. Following a file through history now copes better when it was renamed differently on separate branches.

git history drop --dry-run <commit>
git branch --dry-run --delete-merged 'origin/*'
git refs create refs/heads/hotfix HEAD

Try It in Five Minutes

Create a repository with all of the Git 3.0 defaults and look at it.

git --version
git init --object-format=sha256 --ref-format=reftable -b main demo
cd demo
git rev-parse --show-object-format --show-ref-format
git commit --allow-empty -m "first commit"
git rev-parse HEAD

The last command prints a 64-character ID. To make your own machine behave like Git 3.0 for new repositories, set the defaults in your global configuration. Leave out the object format line if you push to GitHub.

git config --global init.defaultBranch main
git config --global init.defaultRefFormat reftable
git config --global init.defaultObjectFormat sha256
git config --global safe.bareRepository explicit

An existing repository can move to reftable with one command on Git 2.46 or newer. Try it on a copy first.

git refs migrate --ref-format=reftable
git rev-parse --show-ref-format

The best place for all of this is a test job in CI. Run your pipeline once with these settings and you will know months ahead whether anything in it depends on the old defaults.

Sources

• Git BreakingChanges document
• Johannes Schindelin's summary of the Git Contributor Summit 2026 on the Git mailing list
• GitLab, What's new in Git 2.56.0
• Johannes Schindelin, Git Merge 2026 conference notes
• Git 2.56.0 release notes
• Git 2.55.0 release notes
• Git 2.42.0 release notes
• GitLab, Create a project that uses SHA-256 hashing
• NIST retires the SHA-1 cryptographic algorithm
• SHAttered, the first SHA-1 collision