Git 2.55: the new features you will actually use

Git 2.55 was released on 29 June 2026, with work from over 100 contributors, 33 of them new. Like most Git releases, the bulk of it is invisible: faster packing, less memory in the diff engine, groundwork for the ongoing move to Rust. You will get all of that for free the moment you upgrade, with nothing to configure.

But a handful of changes are things you will type with your own hands. This post covers those — what they do, what they replace, and the exact commands — so you can decide which ones are worth adopting this week.

Everything below is checked against the official Git 2.55 release notes and the GitHub highlights post. Two of these features (git history and git format-rev) are new and still settling in, so treat their exact behaviour as subject to change and keep an eye on the docs.

1. git history fixup — amend an older commit in one step

This is the change most people will feel day to day.

You have a branch of, say, five commits. You are working on the top one when you notice a small mistake in commit three — a typo in a variable name, a missing file. You want that fix to land inside commit three, not as a sixth "fix typo" commit on top.

Until now, the clean way to do this took three steps:

git add -p                          # stage just the fix
git commit --fixup=<sha-of-commit-3>
git rebase -i --autosquash <sha-of-commit-3>~1

That works, but it is a lot of ceremony for a one-line fix, and the interactive rebase drops you into an editor you then have to save and close.

Git 2.55 collapses it into a single command:

git add -p                # stage just the fix
git history fixup <sha-of-commit-3>

git history fixup takes what you have staged, folds it into the commit you name, and replays every commit that came after it. By default it keeps that commit's original message and author. If the fix touches lines that later commits also changed and a conflict results, it stops and aborts cleanly rather than leaving you stranded in the middle of a rebase — so you are never worse off than when you started. (It needs a normal working tree; it will not run in a bare repository.)

If you already understand --fixup and --autosquash, this is the same idea with the ritual removed. If you do not, the mechanics behind it are worth learning first — that is exactly what interactive rebase does under the hood. Walk through it in the Interactive Rebase lesson, then let git history fixup be the shortcut.

2. git checkout -m no longer forces you to resolve conflicts on the spot

git checkout -m <branch> (also git switch -m) lets you carry your uncommitted local changes across to another branch, doing a three-way merge so your edits land on top of the branch you are moving to.

The rough edge was what happened when a file you had edited also differed between the two branches. Git would drop conflict markers into your working tree, and you had to resolve them right then, before you could do anything else. If you just wanted to hop over to check something, that was a poor trade.

In 2.55, when git checkout -m hits conflicting paths, Git saves your local changes as a stash entry instead of leaving a conflicted mess in place. You switch branches cleanly, and your work is waiting in the stash for you to apply and resolve when you are ready:

git checkout -m other-branch
# conflicting local changes are stashed, not forced on you
git stash list        # your changes are safe here

This is the same safety principle behind the stash-pop conflict behaviour: a conflict should never be able to lose your work.

3. fsmonitor now works on Linux

git status is slow on very large repositories because Git has to scan the whole working tree to see what changed. The fix has existed for years — a filesystem monitor daemon that Git can ask "what changed since last time?" instead of walking every file — but it only shipped for macOS and Windows.

Git 2.55 adds an fsmonitor daemon for Linux, built on inotify. Turn it on with:

git config core.fsmonitor true

After that, git status, git add, and anything else that checks the working tree get noticeably faster on a big repo, because Git consults the daemon rather than scanning.

Two honest caveats. fsmonitor needs one inotify watch per directory, so on a repository with tens of thousands of folders you may hit the kernel's default limit and need to raise fs.inotify.max_user_watches. And repositories on network mounts remain opt-in, because file-change notifications are not reliable there.

If you are unclear on why git status does what it does, the Status, Log & Diff lesson covers the model this speeds up.

4. Configured hooks can run in parallel

Git 2.54 introduced hooks defined through configuration (rather than only as scripts in .git/hooks). Git 2.55 lets independent ones run at the same time.

If your pre-commit stage runs, say, a linter and a separate test command, and neither depends on the other, you can let them run concurrently:

git config hook.<name>.parallel true
git config hook.jobs 4            # overall concurrency

Hooks that touch shared state — anything that reads or rewrites the index, or edits the commit message — stay serial on purpose, because running those in parallel would race. This is opt-in per hook, so nothing changes until you ask for it. If you have not set up hooks before, start with the Hooks & Automation lesson.

5. Push to several remotes at once

If you mirror a repository to more than one place — a primary, a backup, a public mirror — you can now group those remotes under one name and push to all of them in a single command:

git config remotes.publish "origin backup mirror"
git push publish main

One caveat worth knowing before you rely on it: --atomic is not supported for a remote group. Atomicity means "all refs update or none do," and Git cannot guarantee that across several separate network connections. Each remote in the group succeeds or fails on its own.

The smaller niceties

A few changes that will not change your life but are pleasant to discover:

• A safety net for a common config mistake. Running git config foo.bar=baz (the old positional style) now warns you that it looks like a typo for the modern git config set foo.bar baz, instead of silently doing something you did not mean.
• Tidier git log --graph. You can now cap how many lanes the graph draws; anything beyond the limit is collapsed to a ~, which keeps histories with many parallel branches readable.
• --max-count-oldest=<n>. git log and git rev-list can now return the oldest N commits in a range directly, instead of the old --reverse | tail dance.
• git format-rev. A new builtin that pretty-formats revision expressions read from standard input — handy for turning a stream of commit hashes into author names or subjects without spawning a Git process per line.
• git url-parse. Git's internal URL parsing is now exposed as a subcommand, which is useful in scripts that need to handle remote URLs the same way Git does.
• A quiet security fix. Progress messages a remote sends back over the sideband channel can no longer move your cursor or erase text — Git now strips terminal control sequences from that stream by default, while still allowing plain ANSI colours. It closes a small avenue for a hostile server to mess with your terminal.

Under the hood (nothing to do, just faster)

You do not have to touch any of this, but it is where most of the release actually went:

• Incremental multi-pack-index repacking. Large repositories can maintain their pack metadata by appending new layers instead of rewriting everything, which keeps routine maintenance cheap as the repo grows.
• Faster reachability bitmap generation, through smarter tree traversal and caching — this is what makes clones and fetches of big repositories quicker.
• Rust groundwork. The codebase continues preparing for optional Rust components (with a way to opt out). Nothing user-visible yet; it is scaffolding for later.

If you maintain a monorepo, these are the changes that quietly pay for the upgrade.

How to get it

Check what you are on:

git --version

If it is below 2.55.0, upgrade through your package manager (brew upgrade git, apt, winget, and so on) or from git-scm.com/downloads. The user-facing features above only exist once you are on 2.55.

What to actually try this week

Two things earn their keep immediately:

1. git history fixup — if you ever amend older commits (and if you review your own history before pushing, you do), this removes the most tedious three-step ritual in everyday Git.
2. git config core.fsmonitor true — if git status feels slow, this is close to free speed on Linux now, the same way it already was on macOS and Windows.

The rest is worth knowing so you recognise it when you need it. And if any of these commands assume knowledge you would rather have solid first — rebase, hooks, the status model — the lessons build exactly that, in a real terminal, before you reach for the shortcut.