<p>git checkout 本身不合并，仅覆盖指定文件：用 git checkout <branch> -- <path> 或 git restore -s <branch> -- <path> 可快速复制单个文件内容，但会丢弃当前修改，不解决冲突。</p>
git checkout 怎么合并单个文件（从其他分支）
直接说结论：git checkout 本身不“合并”，它只是把指定版本的文件内容复制到工作区——如果你要的是“把 feature 分支里某个文件的改动拿过来，不碰其他文件”，用 git checkout <branch> -- <path> 最快，但要注意它会完全覆盖当前工作区该文件的内容，不解决冲突。
常见错误现象：执行 git checkout feature-branch -- src/utils.js 后发现文件变了，但之前在 main 上改的同名函数没了——因为 checkout 是“覆盖”，不是“合并”。它不比较行级差异，也不调用合并策略。
- 适用场景：你确定目标分支的该文件就是最终想要的版本，且当前工作区没有需要保留的修改
- 路径必须写对，相对项目根目录；如果文件已暂存（staged），需加
--force或先git restore --staged - Git 2.23+ 推荐用
git restore -s <branch> -- <path>替代，语义更清晰，但底层行为一致
git restore -s 怎么安全地拉取单个文件
git restore 是 checkout 的语义拆分替代命令，-s（--source）指定源树，-- 后跟路径，和 checkout 效果一样，但不会意外切换分支——这是它唯一优势。
容易踩的坑：git restore -s feature -- README.md 如果当前有未提交的 README.md 修改，它会直接丢弃那些修改，不提示、不备份。Git 不认为这是“合并”，所以不会生成冲突标记。
- 想保留当前修改？先
git stash push -p暂存该文件的改动，再 restore，最后git stash pop - 不确定要不要覆盖？先
git diff feature:README.md README.md看差异 -
restore不支持merge风格的三方合并（比如 base + ours + theirs），别指望它处理部分行冲突
真要“合并”单个文件（保留双方修改）怎么办
Git 没有内置的“单文件三路合并”命令。所谓“合并某个文件”，本质是手动触发一次局部合并过程：找到共同祖先、取出 ours/theirs 版本，再用 git merge-file 工具合成。
实操步骤（以把 feature 分支的 package.json 合并进当前 main 分支为例）：
- 确认共同祖先：
git merge-base HEAD feature→ 得到 commit hash - 提取三个版本：
git show <ancestor>:package.json > base.json，git show HEAD:package.json > ours.json，git show feature:package.json > theirs.json - 运行合并：
git merge-file -p ours.json base.json theirs.json > merged.json，检查结果，再mv merged.json package.json - 最后
git add package.json提交
这个流程麻烦，但它是唯一能真正“合并”而非“覆盖”的方式。多数人卡在第二步——git show 路径必须是 commit 中的完整路径（如 src/index.ts），不能是相对当前目录的简写。
为什么 git merge --no-commit 不适合“只合一个文件”
git merge --no-commit feature 会把整个分支所有变更拉进来，只是暂停提交。你删掉其他文件的暂存（git reset <other-files>），只 git add target.js，看起来像“只合了一个文件”，但问题很大：
- Git 内部仍记录了完整合并关系（
git log --merges会显示这次合并），后续git rebase或git revert可能误操作其他文件 - 如果目标文件在 merge 过程中产生冲突，你 resolve 后只
add它，其他冲突文件仍处于 unmerged 状态，git status会持续报错 - CI/CD 流水线可能基于
git diff HEAD^ HEAD判定变更范围，这时它看到的是全部改动，不是你主观认定的“就一个文件”
真正需要精确控制粒度时，老实用 checkout 或 restore 覆盖，或手撸 merge-file。想省事又求稳妥，不如直接切到目标分支改完再 cherry-pick 提交——毕竟 Git 的原子单位是 commit，不是 file。
