git checkout -- 不安全但可控，它硬覆盖工作区和暂存区，不提交、不改head；推荐用 git restore --source 更清晰，语义明确且更安全。

git checkout 从源分支提取文件到当前分支是否安全？

不安全，但可控——git checkout <source-branch> -- <path></path></source-branch> 本质是把源分支对应路径的快照“硬覆盖”到工作区和暂存区，不会自动提交，也不会影响其他文件。它适合单向同步，但容易误删当前分支已修改但未提交的本地改动。

• 执行前务必确认当前分支没有未提交的、与目标路径冲突的修改，否则会被静默覆盖
• 如果目标路径在当前分支已被删除，git checkout 会把它重新检出；如果已被重命名或移动，不会自动处理，需手动清理
• 该命令不改变 HEAD 或分支指针，只改工作区/暂存区，所以可以放心预演：git checkout <source-branch> -- <path> && git diff --staged</path></source-branch>

用 git restore --source 替代 checkout 更清晰吗？

是的，Git 2.23+ 推荐用 git restore，语义更明确：它专为“恢复/覆盖文件”设计，且默认只操作工作区，加 --staged 才影响暂存区，比 checkout 少歧义。

• 仅覆盖工作区（保留暂存区原有状态）：git restore --source=main src/utils/ --worktree
• 同时覆盖工作区和暂存区（等效于旧版 checkout）：git restore --source=main src/utils/ --worktree --staged
• --source 必须指定分支名或 commit，不能省略；不支持通配符，目录需以 / 结尾或显式列出
• 注意：若目标路径在当前分支有未追踪文件，restore 默认不覆盖它们（除非加 --force），这点比 checkout 更保守

同步整个目录但排除部分子文件时怎么写？

Git 没有原生“exclude”参数，得靠两次操作：先全量恢复，再手动重置排除项。别试图用 .gitignore 干这事——它只管未跟踪文件，对已跟踪文件无效。

batch-git-url-replace

批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。

下载

• 例如：同步 docs/ 但排除 docs/internal/ 和 docs/config.md：

  git restore --source=stable docs/ --worktree --staged<br>git restore docs/internal/ docs/config.md --worktree --staged

• 第二步的 git restore 不带 --source，表示恢复成当前分支的版本（即“撤回上一步对它们的修改”）
• 如果排除项很多，建议先 git status --porcelain docs/ | grep -E '^(M|A|D)' | cut -d' ' -f2- 看哪些真被改了，再精准还原，避免误操作

为什么不用 merge 或 cherry-pick？

因为它们是“合并变更”，不是“同步内容”。如果你只想要文件内容一致，而不在乎提交历史、冲突逻辑或父提交关系，merge/cherry-pick 反而引入不必要的复杂性——比如冲突提示、自动提交、甚至意外合入其他文件的改动。

• merge 会尝试计算共同祖先，一旦源分支和当前分支在目标路径上有不同修改，必然触发冲突，哪怕你只想拿最新内容
• cherry-pick 针对的是 commit，不是文件路径；想挑某个 commit 中特定文件的改动，得用 git checkout <commit> -- <path></path></commit>，本质又回到第一种方式
• 真正需要保留历史追溯时，才考虑 git subtree push/pull 或子模块，但那是另一层架构决策，不是单次同步需求

最简路径就是 git restore --source=<branch></branch>，前提是清楚自己要的是“内容快照”，而不是“变更集成”。路径级同步永远绕不开手动校验——尤其当目标分支存在同名但语义不同的文件时，Git 不会提醒你逻辑冲突，只认 SHA。