遇到“手头正干着活，临时要改另一个分支的某个文件”这种需求，常见的反应是先用git stash保存进度，再checkout过去，改完提交再切回来。但这套流程在改动多、分支乱的时候容易出错。其实可以把“切不切换”拆开看：Git支持多工作树，也支持选择性取文件，关键是先分清自己到底想“借”还是“改”。

先想清楚：你要的是“借用”还是“修改”

如果你只是想看一眼旧版本、临时把某个文件拷过来用，那属于“取文件”，用restore就能完成。但如果你想在另一个分支上产生一次新提交，把这次修改留在他那边，那本质上就要求“目标分支的工作区”有一个新的commit。这两个目标的操作路径完全不同，很多问题出在没分清这一点。

worktree 并行工作区：最直接的做法

当需要修改另一个分支上的某个文件，但又不想中断当前工作区的状态时，可以借助git worktree。前提是目标分支没有被任何工作树检出，且你当前的分支有未提交的改动也不受影响。做法是：先执行git worktree add ../other-branch other-branch，在生成的临时目录中打开目标分支的副本，直接编辑并提交该文件；完成后在原来的仓库根目录下执行git worktree remove ../other-branch。这样目标分支的提交记录会同步更新，而当前分支的工作区保持不变。这个方法的优势是全程不需要切换HEAD，适合并行修改多个分支的场景。

实际操作时，临时目录建议放在仓库目录外，避免嵌套带来的递归搜索问题。比如当前仓库在 /srv/app，就把另一个分支检到 /srv/app-hotfix，然后用cd ../hotfix进去改。一个完整的流程是这样的：

git worktree add ../hotfix another-branch
cd ../hotfix
# 编辑目标文件，比如调整 nginx.conf
git commit -m "fix: adjust setting"
cd ..
git worktree remove ../hotfix

注意，一个分支同时只能被一个工作树检出。如果目标分支已经在别的目录里打开，git worktree add 会直接报错，这是保护机制，不是配置问题。这种情况下先对旧工作树进行worktree remove，再重新添加。

git restore 只是取文件，不是写回分支

有些开发者习惯使用git restore --source= -- ，它的作用是把目标分支中的文件复制到当前工作区和暂存区，本质上是“取文件”，而不是“改文件”。如果你只是想沿用旧分支中的某个版本，可以这么做；但如果你希望把修改写回那个分支，则仍然需要先切换分支再提交，或者借助工作树。常见误区是误以为restore会改变目标分支的引用，实际上它只影响当前分支。因此，使用前请确认你的真实意图：是“借用”还是“修改”。判断依据很简单：如果操作后还需要在目标分支上产生新的提交，那么restore不满足需求。

使用restore时，把命令补全就是git restore --source=target-branch -- path/to/file，实际操作时把target-branch和path/to/file替换成你的分支和文件路径。这个命令会把目标分支里的文件内容覆盖到当前工作区并加入暂存区，但不会对target-branch产生任何写入。什么时候适合用它？比如你要对比两个分支的某个配置文件，或者临时把旧版本的方法copy过来看看。restore不能替代提交。

如果你用的是旧版Git，还没有restore命令，可以用git checkout <target-branch> -- <path>达到同样效果。需要注意的是，这同样只影响当前分支。

补丁方式适合改动较多、需要审查的场景

如果你的改动已经整理成补丁，比如一次涉及多个文件，也可以先用git diff生成patch，再拿到目标分支的临时工作树上应用。思路是：在当前分支基于共同祖先生成diff，然后worktree一个目标分支的副本，在副本里git apply那个patch，最后提交。补丁方式适合改动多、需要事先review的场景，因为补丁可以单独保存、传给其他成员检查。

但补丁方式有一个前提：补丁内容必须能干净地落到目标分支上。如果目标分支已经改过同一段代码，apply时会出现冲突，需要手动解决。对单个文件来说，直接worktree编辑往往更省事，补丁更适合批量变更或跨分支协作。

改完后怎么确认改动真的进了目标分支

不管用哪种方式，提交完都要在目标分支之外验证一下。最直接的办法是用git log -- <file>看目标分支最后一条提交，再用git show <branch>:<file>打印文件内容，确认和预期一致。如果你刚才用的是worktree方案，回到原仓库后，git log another-branch --oneline -1应该能看到新提交。

git log --oneline -3 another-branch -- path/to/file
git show another-branch:path/to/file

还要检查远程分支的同步状态。如果另一个分支有对应的远程跟踪分支，执行git log origin/another-branch对比一下本地引用是否落后。如果改动“找不到了”，最常见的原因是只改了临时工作树的文件但没有git commit，或者把worktree remove时没确认提交状态。

不要碰 .git 底层的 ref 和 object

需要特别提醒的是，不要尝试直接改动.git目录下的object或ref来“修改”另一个分支的文件，这属于底层操作，极易破坏仓库完整性。Git不会主动检测这种手动改动，直到下一次gc或fsck时才会报错。即使你成功修改了ref指向的commit，也只会得到一个dangling对象，因为原有commit的哈希已不可变，任何修改都必须生成新的commit。因此，所有常规方法的核心都是“先创建新提交，再移动分支指针”。理解这一点，就能避开很多危险的实验。安全边界在于：任何修改至少要有一次提交动作，且分支指针的移动只能通过git update-ref或git branch -f等规范命令完成。

所以，回到最初的问题：不切换分支修改另一个分支的文件，最稳的路径就是worktree开一个临时工作树，改完提交、移除。restore只适合“取文件”而不是“留提交”。补丁方式可以应对批量改动。这三件事想清楚，分支操作就不会出大乱子。