Git 2.56 released: a safer way to finish merge conflicts, faster history searches and smaller repository storage, as described by GitHub

What happened

On 28 September 2026 the GitHub Blog published a post by Elijah Newren saying the open source Git project has just released Git 2.56.0. Git is the version-control tool that developers use to track changes to code. According to GitHub, the release includes features and bug fixes from more than 104 contributors, 39 of whom are new. The post picks out the changes GitHub considers most noteworthy. The main ones are a safer way to stage conflicts, faster merge-base search, and making path-walk repacks better suited to server use.

Three key changes

Read the full description

Sources are collected, independently checked, then reviewed by Jev.

git add --resolved: stage only resolved conflicts

A merge conflict happens when two sets of changes touch the same part of a file and Git cannot combine them on its own. Git marks the clash inside the file with conflict markers, and the developer edits the file to settle it. The developer then stages the file, which means marking it as ready to include in the next commit. As GitHub explains, the commonly used git add -u stages every modified tracked file. That means it can also stage local changes unrelated to the conflict, and even files that still contain conflict markers. The new git add --resolved in Git 2.56 considers only paths that are currently unmerged in the index, Git's list of what is staged. Before staging, it scans those files for leftover conflict markers. If it finds any, it lists the affected paths and leaves the index unchanged.

$ git add --resolved
fatal: the following paths still have conflict markers: recipe.txt
$ # Edit recipe.txt and remove the conflict markers.
$ git add --resolved
$ git status --short
 M notes.txt
M  recipe.txt

In this example, recipe.txt is staged once its markers are removed. The unrelated edit to notes.txt stays unstaged. GitHub adds that the command can be limited with a pathspec, a pattern that selects which files to consider. Within that selection the check is all-or-nothing: if any selected file still has markers, nothing is staged. Resolved deletions and binary conflicts have no text markers and are staged normally. The command cannot be combined with git add -u or git add -A, and it ignores tracked files that were never in conflict.

Merge-base search can stop early

A merge base is the best common ancestor of two commits: the most recent shared point in their histories. Merges, three-dot diffs (comparisons showing what one branch changed since the two split) and pull request comparisons on hosting platforms all need to find it. According to GitHub, the old stopping rule could keep processing large amounts of old history even after no new merge base was possible. Git 2.56 tracks how many queued commits are still reached from only one side. As soon as one side runs out, it can stop, while still returning all merge bases.

Path-walk repacks now work with bitmaps and delta islands

Git periodically repacks a repository, compressing its stored data by saving similar objects as deltas, meaning differences from each other. According to GitHub, a path-walk repack visits objects by their location in the file tree, which often finds better delta pairings. Hosting platforms commonly rely on reachability bitmaps, which are indexes that let them quickly work out which objects to send. Some also use delta islands, rules that stop objects in one group of references from depending on objects that exist only in another group. Path-walk repacks used to be incompatible with both, and Git 2.56 removes these two restrictions. GitHub stresses, however, that the new version does not enable path-walk repacks by default. It only lets hosts of large repositories evaluate the storage savings.

Performance figures published by GitHub

Other new commands worth noting

• git history drop: according to GitHub, the experimental git history command gained reword and split in Git 2.54, and fixup in Git 2.55. Git 2.56 adds drop, which removes the selected commit and replays the commits that came after it onto its parent. It stops if the replay would conflict or overwrite local changes. It cannot handle history containing merge commits, and it cannot remove a root or merge commit.
• git refs tooling: refs are the named pointers behind branches and tags. Git 2.56 continues bringing low-level ref management together under git refs, including create, update, delete and rename. GitHub notes that git refs rename moves a ref and its reflog (the record of where that ref has pointed). It does not, however, make the branch configuration adjustments that git branch -m does.
• git branch --delete-merged: GitHub says the new version adds a way to delete, in bulk, local topic branches whose work has landed upstream. The example in the post uses the --dry-run option.

What it means for everyday users

For developers who use Git daily, the most direct change is git add --resolved. When unrelated local changes already exist during a merge, it acts as a safety rail that reduces the chance of accidentally staging unfinished conflicts or unrelated edits. The merge-base search improvement mainly affects repositories with large histories and many merges of old branches. The path-walk changes mainly concern repository hosts. Non-developers generally won't touch these changes directly, though the code hosting services they use may benefit in future. Whether and when to upgrade should depend on a team's own toolchain and compatibility needs.

Browse the latest news in this topic

• Tech news