Git 2.56 goes after the merge, diff and branch chores that eat CI minutes

I once pushed a commit with a <<<<<<< marker still sitting in a YAML file. CI caught it, eventually, after a full install and a lint step, and I spent the next ten minutes watching a red pipeline for a mistake I could have seen in my editor. Git 2.56 has a flag aimed squarely at that moment, and a handful of other changes I expect to feel more in CI than at my desk.

DevOps.com covered the release on September 30. It touches merge safety, speeds up operations on large repositories, and adds cleanup tooling that the write-up positions as useful for AI coding agents and busy DevOps teams alike.

The commands that are new or different

The merge-side change is git add --resolved. It limits staging to the unresolved paths from a conflict and scans them for leftover conflict markers before staging anything. That is my YAML file, stopped before it ever left the laptop.

Branch sprawl gets git branch --delete-merged, which removes branches that are already merged. It supports pattern matching and a --dry-run flag, so you can see the list before anything disappears.

Bisecting gets git bisect run --reset-when-found, which finds the culprit commit and cleans up in the same step. A new git refs command groups the low-level reference operations (create, update, delete, rename), with optional checks on the old value.

Two smaller ones made me smile. git log --follow tracks paths better through non-linear history. And if you type git push origin/main, Git now catches the slip and suggests git push origin main.

What the speedups mean for a runner

Here is where my DX brain lights up, because CI runs these operations on every job, often against a cold or shallow checkout. The figures in the DevOps.com piece:

• git merge-base --all v4.8 v4.9 on the Linux kernel went from 167,441 steps and 0.29 seconds to 3,887 steps and 0.01 seconds.
• A monorepo merge-base dropped from 0.68 seconds to 0.01 seconds.
• A path-limited diff in Chromium, with 500k index entries, went from roughly eight minutes to 0.07 seconds.
• Loading a repository with 37,815 packs went from 4.5 seconds to near-instant.

Eight minutes to under a tenth of a second is the one I keep rereading. Path-limited diffs are exactly what "only run this job if services/api/ changed" logic does in a lot of monorepo pipelines. If you have ever wondered why your change-detection step takes longer than the tests it gates, this is worth checking.

There is a storage story too. git repack --path-walk now works with reachability bitmaps and delta islands. On the Fluent UI repository, a bitmapped repack came out at 558.5 MB, while the --path-walk repack came out at 164.4 MB, 71% smaller. A new git repack --drop-filtered removes blobs matching a filter, such as files over 1 MB. If you run your own Git server or mirror, smaller packs mean less to fetch per clone.

Kicking the tyres safely

I'd start with the two commands that fit an existing habit. Try the branch cleanup on a scratch clone first:

git --version        # confirm 2.56 or later before relying on any of this
git branch --delete-merged --dry-run

Check git branch -h on your install for the exact pattern syntax before you script it. For bisecting, swap your usual test script into the run step:

git bisect start <bad-commit> <good-commit>
git bisect run --reset-when-found ./path/to/your-test.sh

Where I'd slow down

Two of the new commands are marked experimental. git history drop removes a selected commit and replays its descendants onto the parent, and git replay --linearize flattens merge topology without touching the working tree. Both rewrite history. I'd keep them out of shared automation until they lose the experimental label.

The bigger practical catch is version drift. Your laptop, your hosted runner image and your self-hosted runner can all ship different Git builds, and none of the speedups apply until the runner actually has 2.56. Add a git --version line to a job log before you credit Git for a faster pipeline.

How teams get by today

Most of what 2.56 adds, people have been scripting around for years. Branch cleanup is usually a git branch --merged loop piped into git branch -d, or a hosting setting that deletes the head branch after a pull request merges. Conflict markers get caught by pre-commit hooks or a lint step in CI, which is the slow path I described at the top. Large-repo pain gets handled with shallow clones, partial clones and sparse checkout, which cut how much you fetch but do nothing for the cost of the operations you then run. Native commands mean one less hand-rolled script per repository.

The DevOps.com piece cites Mitch Ashley of The Futurum Group, who argues the release matters because AI coding agents now exercise Git at machine speed. That matches what I see: an agent opening branches all afternoon creates sprawl faster than any of us did by hand. The release came from 104 developers, 39 of them first-time contributors.

What I want to find out next is how long it takes for 2.56 to land on the runner images I actually use. I'll be adding a version check to a few pipelines this week, and if you've already measured the diff speedup on your own monorepo, I'd love to hear the numbers.