Git turned 20 in 2025, and for most developers it’s simply what version control is. That makes it easy to assume nothing much is changing. In fact, quite a lot is. Git itself is preparing its first major version bump since 2014, with changes that will affect every new repository. And a new generation of tools built on top of Git’s storage is rethinking how people interact with it day to day.
This is a look at what’s actually happening, based on the Git project’s own documentation and the tools people are using now, rather than predictions about AI or blockchain replacing everything.
Git 3.0: when and what
The Git project keeps a public BreakingChanges document listing what will change in Git 3.0. As of September 2026, Git 2.56 is in its release-candidate phase. According to LWN’s coverage, the schedule after that is: Git 2.98 in December 2026 to signal that the transition is close, then Git 2.99, a long-term support release, alongside Git 3.0 in April 2027. Here’s what’s changing.
SHA-256 by default
Git has identified objects with SHA-1 hashes since the beginning. SHA-1 is no longer considered collision-resistant (the SHAttered attack produced a practical collision in 2017), and Git has supported SHA-256 repositories for several years. What’s been missing is a smooth path for the whole ecosystem, including hosting services, CI tools and libraries, to handle it.
Git 3.0 makes SHA-256 the default for newly created repositories. Existing SHA-1 repositories stay supported and aren’t converted automatically. The hard part is interoperability: a SHA-256 repository can’t simply push to a server that only speaks SHA-1, which is why support from big hosts like GitHub has been the main blocker, and why it has taken this long.
“main” as the default branch name
Git has warned for years that the default initial branch name would change. Git 3.0 makes it main instead of master. Most hosting services already default to main, so for many people this just brings the command-line tool into line with what they already see. If scripts in your projects assume master, now is a good time to check them.
Reftable as the default reference backend
Git traditionally stores branches and tags as individual files, plus a packed-refs file. That works, but it gets slow with very large numbers of references and has awkward edge cases on case-insensitive filesystems such as the defaults on Windows and macOS. The reftable format stores references in a compact binary format that’s faster, uses less space and supports atomic updates to many refs at once. Git has supported it since 2.45, and 3.0 makes it the default for new repositories. It matters most for huge repositories: Android’s has hundreds of thousands of refs.
Rust becomes a build requirement
Git has started adding Rust code. The plan was phased: optional in 2.52, enabled by default (but possible to turn off) in 2.55, and mandatory in 3.0. For platforms without a good Rust toolchain, the 2.99 long-term support release will remain available without that dependency. For everyday users, nothing visible changes.
Safer defaults and removals
The safe.bareRepository setting will default to explicit, which stops Git from implicitly treating a bare repository it stumbles on, for example one embedded inside a cloned project, as a repository. That closes off a class of attacks using malicious bare repos.
Several long-deprecated commands and features are being removed, including git whatchanged (use git log --raw), git pack-redundant, and grafts (use git replace). The Git mailing list has seen some pushback from people who still use these, which is exactly why the project announces them years ahead.
What you should do before Git 3.0
- Set your default branch explicitly in scripts and templates, e.g.
git config --global init.defaultBranch main, so nothing depends on the built-in default. - Stop using deprecated commands in scripts. Replace
git whatchangedwithgit log --raw. - Check your tooling for SHA-1 assumptions. Code that assumes object IDs are 40 hex characters will break with SHA-256, which uses 64. You can test with
git init --object-format=sha256. - Try reftable on a test repository with
git init --ref-format=reftableif you run tools that read.git/refsdirectly.
New tools on top of Git
The other big change isn’t in Git itself. It’s in tools that keep Git’s storage and hosting compatibility but offer a different way of working.
Jujutsu (jj)
Jujutsu is an open-source version control system that can use a Git repository as its backend, so you can use it on existing projects and push to GitHub as normal. Its design choices remove a lot of Git’s friction:
- No staging area. The working copy is itself a commit that updates automatically as you edit.
- Conflicts are recorded, not blocking. A rebase with conflicts completes, and you can resolve the conflicts later.
- Automatic rebasing of descendants. Edit an earlier commit and everything built on it is rebased for you.
- An operation log. Almost anything can be undone with
jj undo.
It’s still pre-1.0, but it has a growing user base, and because it works with Git repositories, you can try it without asking your team to change anything.
Sapling
Sapling is Meta’s source control client, open-sourced in 2022. It grew out of Meta’s work scaling Mercurial for a huge monorepo and works with Git repositories and GitHub. Its focus is on stacked commits and a clearer view of your work in progress with its “smartlog”.
Stacked diffs
A related trend is the move towards stacked changes: breaking a feature into a series of small, dependent pull requests that can be reviewed separately. Tools like Graphite, and features in Sapling and Jujutsu, are built around this. The benefit is smaller reviews and less time waiting on one huge pull request.
Better diffs
Line-based diffs are one of Git’s oldest limitations. Move a function or reformat a file and the diff can look like the whole file changed. Structural diff tools parse the code and compare syntax trees instead. Difftastic is a popular open-source example that supports dozens of languages and can be used as Git’s external diff tool:
git config --global diff.external difft
git diffIt won’t replace line diffs for patches and merges, but for reading changes it can make reviews much easier.
What about AI?
AI tools are already part of version control work: drafting commit messages, summarising pull requests and suggesting review comments. Those features live in editors and hosting platforms rather than in Git itself. They’re useful, but the fundamentals haven’t changed. A good commit still needs a clear purpose, small focused commits are still easier to review, and an AI-written summary is only as good as the history it’s summarising.
The bottom line
Version control isn’t about to be replaced. It’s being modernised in two directions at once: Git is fixing long-standing defaults, like SHA-1 and the ref storage format, and new clients like Jujutsu and Sapling are making Git repositories easier to work with. You can prepare for the first with a few configuration changes before April 2027, and try the second on your next project without asking anyone’s permission.
Related reading
- Code Review on GitHub: Setup and Habits That Work
- Private Repository Security: A Practical Checklist
- A Developer’s Guide to Abstract Syntax Trees
Sources: Git BreakingChanges documentation, LWN: Looking forward to Git 2.56 and 3.0, Jujutsu, Sapling, Difftastic.
