The open-source Git project has released Git 2.56.0 with improvements and bug fixes from more than 104 contributors; 39 of the contributors joined the project for the first time. The previous release was Git 2.55.
The new release introduces the `git add –resolved` option to stage only the relevant paths while resolving merge conflicts. This mode evaluates the unmerged paths in the index and checks regular files for remaining conflict markers before staging. If any markers are found, it reports the relevant paths without modifying the index. This allows the resolved `recipe.txt` to be staged without staging local changes unrelated to the conflict, such as those in `notes.txt`. The selection can be narrowed with a path pattern; if any of the selected files contains a marker, none of them are staged. Resolved deletions and binary conflicts are handled normally. The option cannot be combined with `git add -u` or `git add -A`, and it ignores tracked files that were not previously involved in a conflict.
Git 2.56 also speeds up operations that search for common ancestors. Git moves backward from two commit points to find merge bases accessible from both sides. Because criss-cross merges may require multiple bases, the search continues until all bases are identified. The new tracking mechanism detects that no new common point can be formed when pending commits unique to one of the sides have been exhausted, and stops the search while preserving all merge bases.
Why it matters
The new staging mode allows developers dealing with merge conflicts to separate files whose conflicts have been resolved without mixing them with local changes, reducing the risk of errors, particularly for teams carrying out different edits in the same working directory. Checking for conflict markers provides an additional safeguard against accidentally staging unfinished content. The improvement to common ancestor searches affects how Git accesses the necessary history in repositories with multi-branch and criss-cross merges. Thus, the release targets not only the introduction of a new command but also the behavior of operations running on complex histories. However, the extent to which these changes will be adopted across different workflows and the repositories in which the performance gains will become noticeable remain unclear.