Git 2.56 adds git add --resolved to keep unrelated edits out of merge commits

Git 2.56 lands with a fix for one of version control's most common small accidents: sweeping unrelated working-tree changes into a merge commit while you are busy resolving conflicts. According to a dev.to walkthrough, the headline addition for everyday work is git add --resolved, a staging command that touches only the files that were actually in conflict and nothing else.

The over-staging trap

The routine goes like this: you fix your conflicts, then you stage the results. Out of habit, most people type git add -u or git add ., and both commands stage every modified tracked file in the repository. Any stray edit sitting in the working tree — a debug print, a set -x line added while troubleshooting something else — rides along into the merge commit.

The dev.to author describes being bitten by exactly this: a debug line quietly landed in a merge commit, went unnoticed because merge commits get far less review than normal commits, and surfaced weeks later when someone asked why the start script was echoing every command. The careful alternative was typing each conflicted path by hand, but even that never verified whether the conflict markers had truly been removed.

What the new flag does

Per the dev.to writeup, git add --resolved behaves as follows:

• It looks only at unmerged paths — the UU, AA and UD entries that appear in git status.
• It checks each of those files for leftover conflict markers.
• If any file still contains markers, it refuses to stage anything and lists the files needing more work.
• Otherwise, it stages all of them, while tracked files that are not in conflict are never touched.

The command also accepts a pathspec to narrow its scope, for example git add --resolved config.ini, and it cannot be combined with -u or -A.

The author walks through a demonstration repository where two branches edit adjacent lines in a config file, producing conflicts in two files while an unrelated local change to a start script sits unstaged. The point of the exercise is keeping those two groups separate until the merge is finished — which the new flag does automatically.

Other changes in 2.56

The dev.to article characterises 2.56 as a substantial release, and lists several other quality-of-life improvements:

• git branch --delete-merged removes local branches whose work has landed in their tracked upstream, with safety rules that spare the checked-out branch, unmerged branches and those marked to keep.
• git bisect --reset-when-found ends a bisect session on its own once the bad commit is identified.
• git history drop removes a commit from the middle of history, with dependent branches following along.
• A new git refs family (create, update, delete, rename) provides safer ref manipulation with no silent overwrites and a compare-and-swap update.
• git replay --linearize flattens a merge-heavy branch in memory, including in bare repositories.
• git log --graph no longer draws unrelated histories as if they were connected.
• [includeIf "worktree:..."] extends conditional, per-directory configuration to linked worktrees.
• fetch.followRemoteHEAD keeps origin/HEAD in sync with the remote via a single setting.
• git repack --drop-filtered reclaims disk space in partial clones.

Smaller touches include typo hints for push targets — git push origin/main now suggests git push origin main — and -h now exits with code 0 in most commands instead of 129, so a scripted help check no longer reads as a failure.

Getting the new version

Linux distributions take time to package new Git releases; the author reports that Fedora still ships 2.55. Rather than compiling from source, they installed a prebuilt Git 2.56.0 using mise with its conda backend, which is still marked experimental. Configured through a mise.toml file, the newer Git applies only inside that project, leaving the system installation untouched.

Why it matters

Merge conflicts are routine, and the moment right after resolving them is precisely when haste meets commands that assume you want everything staged. git add --resolved moves a safety check that previously depended on personal discipline — and often did not happen at all — into the tool itself. The leftover-marker check is arguably the bigger win: manual staging never confirmed a resolution was complete. Combined with the rest of the release's incremental fixes, it trims the number of ways an ordinary Git workflow can silently go wrong, which is exactly the kind of unglamorous improvement that pays off daily.