git merge 不接受路径参数，因其操作对象是当前工作区而非任意目录；真正实现多目录并行开发需用 git worktree，在不同路径检出不同分支并共享同一.git库。
Git 本身不支持“把远程分支合并到不同目录”——它操作的是工作区（working directory），不是任意路径。所谓“合并到不同目录”，本质是切换工作区或用 git worktree 管理多份检出，或手动复制/重定向文件。直接 git merge 不会、也不能指定目标目录。
为什么 git merge 不接受路径参数
Git 的 merge 命令作用于当前 HEAD 所在分支的整个提交历史和工作区，它没有 --target-dir 或类似选项。你看到的“合并到某目录”，其实是人为控制了工作区位置（比如先 cd /path/to/dir 再执行操作），或是用了 git worktree 在另一路径挂载分支。
- 运行
git merge origin/feature时，Git 只检查当前目录是否为 Git 仓库根目录；如果不是，会报错fatal: not a git repository - 即使你在子目录里执行命令，Git 仍以上层最近的
.git为准，不会把改动“写入”该子目录作为独立目标 - 试图用
git --git-dir=/other/.git merge ...指向另一个仓库，那只是操作另一个仓库，不是“合并到该目录”
真正可行的“多目录”方案：git worktree
如果你需要同时在多个目录里操作不同分支（例如：./main 对应 main 分支，./feature 对应 feature 分支），git worktree 是唯一 Git 原生支持的方式。
- 前提：主仓库已存在（如
~/project/.git），且你有读写权限 - 添加新工作树：
git worktree add ../feature feature—— 这会在上层目录创建feature/文件夹，并自动检出feature分支 - 后续可在
../feature/目录里正常git pull、git merge、git commit，互不干扰 - 注意：
git worktree不支持裸仓库，且删除工作树前需先git worktree remove，否则残留锁文件
常见误操作：用 cp/mv + git add 模拟“合并到目录”
有人想把 origin/dev 的代码“合并进”一个非 Git 目录（如 deploy/），然后手动 cp -r 文件再 git add。这看似可行，但实际破坏了 Git 的跟踪逻辑：
- Git 不知道这些文件来自哪个分支、哪次提交，
git log -- path查不到来源 - 下次再想更新
deploy/，无法用git merge自动处理变更，只能重复手工覆盖 - 如果
deploy/本身是子模块或 submodule，更不能这么干——会破坏.gitmodules和提交哈希绑定 - 正确替代做法：用
git archive导出干净快照：git archive --format=tar --output=deploy.tar origin/dev .，再解压
合并远程分支前必须同步本地分支，否则目录内容不可信
很多人在 ./feature 工作树里执行 git merge origin/main，却发现合并后文件没变，或者 git status 显示 “Your branch is behind”。根本原因是：工作树所在分支的本地提交落后于远程。
- 务必先
git checkout main && git pull（或git -C ../main pull），确保本地main分支 HEAD 是最新的 - 再切回
./feature工作树，执行git merge main—— 此时才是真正的“把最新主线合并进 feature 目录” - 跳过
git pull直接git merge origin/main，Git 会尝试合并远程引用，但若本地没有对应origin/main的 ref（比如刚初始化 worktree），会失败或静默忽略
真正要让“不同目录”反映不同分支状态，核心就两点：用 git worktree 而非手工挪文件；每次 merge 前确认目标分支的本地 ref 已更新。其余所有“绕过 Git 机制去拼目录”的做法，短期省事，长期必踩追溯、协作、CI 同步的坑。
