Git 2.56 新增 add --resolved：只暂存已解决的冲突文件

GitHub在2026年9月28日介绍Git 2.56发布亮点，其中一项是git add --resolved。该模式只处理索引中处于未合并状态的路径，并在暂存前检查普通文件是否残留冲突标记。如果选中的文件中仍存在标记，会报告问题并保持索引不变。官方发布解读。

图：AI生成版本控制概念配图，非Git实际输出。

这项改变解决的是提交范围问题

合并时，工作目录中可能还有与冲突无关的改动。范围较大的暂存命令容易把它们一起带入提交；新模式把注意力收窄到冲突路径。官方说明还指出，删除与二进制冲突没有文本标记，仍需理解具体解决结果，不能把一次命令成功当作业务逻辑已经正确。

实际建议：把“已解决”拆成两次判断

第一次判断是文本和索引状态：冲突是否已处理、是否只暂存预期文件。第二次判断是行为：合并后的代码是否同时保留双方需要的逻辑。例如，一边增加参数校验，另一边调整返回格式，删除冲突分隔线并不保证两项改动都被正确保留。

因此可以先在临时测试分支体验新命令，观察状态和暂存区差异，再运行对应测试。已经有未提交工作时，先记录哪些文件属于本次合并、哪些属于其他任务；不要为了使用新功能而把原有修改随意清理掉。命令越方便，越值得保留一次完整差异审阅。

脚本升级要确认实际执行的是哪个Git

新选项依赖相应版本。开发机、持续集成镜像和IDE内置工具可能不一致，更新系统安装包之后，也应确认自动化环境实际调用的版本。对于给多人使用的脚本，不要在未说明最低版本的情况下直接加入新参数，否则一部分机器会在合并流程中突然失败。

这项更新的价值是减少无关文件混入冲突解决提交的机会。它并没有取消代码评审，也不保证冲突双方的意图被保留。将范围控制交给工具，把行为正确性留给测试与审阅，是更稳妥的分工。

核对时间：2026年10月1日（北京时间）。发布事实以所链接的一手资料为依据，实践建议为本站独立解读；预览状态与可用范围可能变化。