小丸子书单做开发的这些年，我经历过的所有 Git 事故，几乎都发生在任务切换的时候。改了一半的接口、刚写完的单元测试、还没来得及提交的调试代码……一个突如其来的线上问题，就能把这些全都搅成一团乱麻。Git 本身不复杂，复杂的是我们总在多个任务、多个分支、多个上下文之间反复横跳。这篇文章就是一份来自一线的 Git 任务切换实战记录：从 stash 到 worktree，从 cherry-pick 到 revert，每一步都写清楚为什么这么做、踩过什么坑。不管你是刚入职的新人，还是已经带过几个项目的开发，这套流程都能帮你把切换成本降到最低，至少做到"勉强拿捏"。
1. 任务切换为什么总是手忙脚乱：先看清事故源头
1.1 工作区里的"半成品"才是万恶之源
很多人以为任务切换的难点在命令记不熟，其实真正的问题出在工作区。你可以在一个毫秒级的时间里切换分支，但 Git 有一个硬性约束：它不允许你把没提交的改动直接带到另一个分支上。当你执行 git checkout 时，如果当前分支的工作区有未提交的修改，Git 会尝试把这些修改一起带过去——能带过去的前提是目标分支和当前分支在这些文件上没有冲突。一旦冲突，Git 直接拒绝切换，报出一堆 error: Your local changes would be overwritten by checkout。
这个设计本身是保护机制，但它把"切换任务"这个动作变成了一场赌博：你赌的是手头这些改动和新分支之间没有交集。可惜大多数情况下，改动往往集中在公共模块，于是冲突就成了家常便饭。
另一个隐蔽的坑是"假切换成功"。比如你在 master 上有一个改动，git checkout dev 之后发现居然切过去了，改动也跟着过去了，然后你在 dev 上继续写、顺手 commit，最后才发现这个 commit 进错了分支。Git 不拦你，是因为这个文件在两个分支上内容一致，改动可以无损转移。但这种"自动携带"恰恰是最容易制造混乱的地方——你以为自己在 master 上干活，实际提交已经落到了 dev。
1.2 切换前把四件事问清楚，能避开八成事故
我在踩了无数坑之后，给自己规定了一个强制流程：任何一次任务切换之前，先回答四个问题，回答完了再动手。
第一个问题，当前改动到底是保留还是扔掉。调试日志、临时打印这种，直接 git checkout -- 或 git restore 扔掉；有价值的半成品，必须按后面说的方法打包带走，绝不让它裸奔在工作区里。
第二个问题，目标分支从哪里拉。这个很容易被忽视。很多人 git checkout feature/xxx 之前根本不看这个分支是基于谁切出来的。如果它基于一个很旧的 master，你切过去之后面对的是一堆过期代码，甚至要处理一堆和当前工作没关系的冲突。正确的做法是先 git fetch origin，看一下 origin/feature/xxx 和本地分支的差距，再决定是 git pull 还是直接从 origin 拉新分支。
第三个问题，切换过去之后需不需要把现在的改动也带过去。如果需要，你要提前决定用 stash、WIP commit 还是 worktree（这三个方案后面都有专门章节）；如果不需要，那就老老实实把改动处理干净再切，别指望 Git 帮你记住。
第四个问题，有没有未提交的新文件、临时文件混在目录里。git status 里出现的 ?? 未跟踪文件，是不会被 checkout 拦截的，因为它们不在版本控制里。但这类文件往往是配置文件、密钥、IDE 设置，切换分支后它们会原封不动留在原地，等你切回来可能已经被别的任务的脚本改过了。所以切换前扫一眼 git status，把不该存在的文件处理掉，是成本最低的保险。
这四个问题走完一遍，大概花不了十秒钟，但能让任务切换从"碰运气"变成"按流程执行"。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. stash 这个老朋友：临时切换的救命稻草，也是翻车高发区
2.1 stash 的正确用法：给每一笔现场打标签
stash 的基本操作所有人都知道，git stash 把工作区暂存，git stash pop 释放回来。但这个命令的完整能力远不止"暂存"这么简单。
首先要分清三个常用命令：git stash push 是暂存，git stash apply 是"复制"一份回来但保留 stash 记录，git stash pop 是"剪切"回来并删除 stash 记录。任务临时切换用 pop 没问题，但如果你要同时处理多个任务、反复切换，我强烈建议用 apply，因为 pop 一旦遇到冲突或者你后悔了，stash 记录已经没了，想回到原来的现场都难。
其次是给 stash 打消息。git stash push -m "wip: 订单模块接口改造" 和直接 git stash 的区别，就跟文件命名成"新建文档"和"新建文档(最终版)(真的最终版)"的区别一样。git stash list 之后能一眼认出每一笔现场，而不是靠 git stash show 一个个翻。
还有人不知道 stash 可以只暂存部分文件。git stash push -- <file> 只暂存指定文件，这在切换任务时特别有用——你改了 A、B、C 三个文件，但 A 和 B 属于当前任务的半成品，C 是急着要处理的其他内容，那就只把 C 暂存起来。配合 -m 参数，stash 的实用性直接上一个台阶。
2.2 翻车现场一：pop 冲突，现场直接搅成一锅粥
stash pop 的冲突是任务切换时最高频的事故。场景通常是这样的：你 stash 了一个改动，切到另一个分支处理任务，结果处理任务的过程中顺手改了同一个文件，处理完切回来 pop，Git 告诉你 CONFLICT (content)。此时你的 stash 还在（这是好消息），但工作区里已经是一堆带着冲突标记的文件。
这时候最忌讳的是手忙脚乱地 git stash drop，因为 stash 记录一旦删除，你连"重新来"的机会都没有。正确做法是：如果冲突太多理不清，先 git checkout -- . 把工作区恢复到 pop 之前的状态（注意这会丢掉 pop 出来的内容，但 stash 还在，所以不算损失），然后重新 git stash show -p 看看这批改动到底涉及哪些文件，再决定是手动合并还是分文件处理。
我个人处理 stash 冲突的原则是：先恢复现场，再小步合并。别想着一次性把冲突全解完，一次只解一个文件，解一个提交一个，避免把所有冲突混在一起最后无法收场。
2.3 翻车现场二：stash 丢了，怎么捞回来
另一个常见事故是误 drop 了 stash，或者 pop 的时候勾错了选项，stash 记录消失。这时候别慌，Git 的设计决定了它不会立刻物理删除数据，只是从引用中移除。你可以用 git fsck --no-reflogs --unreachable | grep commit 找到那些"悬空"的提交对象，然后用 git show 逐个确认是不是你要找的 stash 内容，确认后用 git stash apply <commit-hash> 把它恢复回来。
这个方法成功率很高，但过程繁琐。所以我后来养成了一个习惯：重要的半成品不放进 stash，而是直接提交成 WIP 分支。这不只是一种"觉得更安全"的心理安慰，而是有实际理由的——WIP 提交躺在分支上，可以用 git log、git diff 查看，可以被 cherry-pick，可以随时 rebase，本质上就是普通提交，完全受 reflog 保护。而 stash 是一个独立于分支历史之外的结构，出了事只能靠 fsck 这种"考古"手段去挖。
2.4 把 stash 当成"临时快递柜"而不是"仓库"
用一句话总结我对 stash 的态度：它适合做"几分钟内切出去看一眼再切回来"这种超短时切换的临时存放，不适合做"可能放好几天"的任务现场保存。好几天的跨度，要么提交成 WIP 分支，要么用下一章说的 worktree。stash 之所以叫 stash，它的定位就是"先放一下"，不是"长期收纳"。
3. git worktree：真正解决多任务并行的钥匙
3.1 worktree 和 branch 到底什么关系
很多人看到 git worktree 和 git branch 区别这个问题时，第一反应是"工作树和分支不是一回事吗"。其实这两个概念一个在讲"指针"，一个在讲"工作目录"。git branch 只是指向某个 commit 的引用，同一个仓库同一时刻只有一个工作目录处于"激活"状态，你切换分支就是在切换这个工作目录指向的 commit。而 git worktree 是给同一个仓库创建多个工作目录，每个目录可以 checkout 不同的分支，互不干扰。
打个比方：branch 是遥控器上的频道，worktree 是再多开一台电视。你用遥控器切频道，那台电视永远只有一个画面；但如果你有两台电视，就能同时看两个频道。任务切换的场景下，branch 让你在 A 任务和 B 任务之间来回切，worktree 让你同时开着 A 任务和 B 任务各自的目录，想改哪个进哪个目录，改动完全隔离，连 stash 都不用。
3.2 worktree 的常用命令和硬性约束
worktree 的使用并不复杂，核心就几个命令。
git worktree add ../project-feature -b feature/order 会在 ../project-feature 目录创建一个新的工作树，并 checkout 新建的 feature/order 分支。注意 add 的时候要么指定 -b 新分支，要么指定一个当前没有被任何 worktree checkout 的已有分支。
git worktree list 查看当前仓库所有工作树及各自所在分支，git worktree remove ../project-feature 移除工作树。如果 worktree 里还有未提交改动，remove 会被拒绝，需要先处理干净，或者用 --force。
硬性约束是：同一个分支只能在一个 worktree 里被 checkout，这是 Git 的保护机制。如果你在别的 worktree 已经 checkout 了 feature/order，再去另一个目录 git checkout feature/order，Git 会报错。实际开发中这不是问题，因为每个 worktree 通常对应一个独立任务、一个独立分支。
还有两个容易忽略的点。第一，worktree 之间共享的是同一个仓库对象库，你在任何一个 worktree 里的 commit、分支、tag 都是全局可见的，所以在一个 worktree 里 git log 能看到另一个 worktree 刚创建的提交——这算好处也算坑，好处是能直观看到全局进度，坑是如果你习惯了"每个目录一个独立项目"的思维，会以为这些提交不该出现在这里。第二，worktree 目录里会有 .git 文件（注意是文件不是目录），这是指向主仓库的指针，别手贱删掉，删了 worktree 就废了。
3.3 我现在的多任务工作流：worktree 是核心
在引入 worktree 之前，我的多任务切换基本就是"stash + 来回 checkout"，一周能翻车两次。现在我的做法是：
每个新任务都开一个独立 worktree，目录名和分支名保持一致，比如任务编号 TASK-1024，就 git worktree add ../proj-TASK-1024 -b TASK-1024。然后我所有的日常开发都在各自的 worktree 里进行，目录之间互不干扰。遇到紧急线上问题时，去主目录（通常是 master/main）直接开一个新的 hotfix 分支，同样用 worktree 拉出来处理。处理完测试完毕，在对应 worktree 里 push、合并，然后移除 worktree。
这套流程的好处是不言而喻的：没有任何 stash、没有任何"切错分支"的顾虑、每个任务的工作区是独立的。代价是需要多开几个终端窗口，以及一定的磁盘空间（每个 worktree 目录会有完整的工作文件，但对象是共享的，磁盘开销不大，主要是工作文件的副本）。
唯一要提醒的是，worktree 不是越多越好。我见过同事一口气开了七八个 worktree，最后自己都忘了哪个目录对应哪个任务。我的经验是同时保持 3 到 5 个是合理的上限，再多就该考虑是不是任务管理本身出了问题。
4. 紧急修复场景：写错分支、改错提交、推错了代码
4.1 在 master 上写了本该属于 dev 的代码，怎么"剪切"过去
这是一个特别经典的翻车现场，也是搜"git 上我在 master 上写的代码怎样剪切到 dev 上"这类问题的根本原因。处理方式取决于你写到什么程度了，分两种情况。
情况一，改动还没提交。这是最好处理的。git stash，然后 git checkout dev，再 git stash pop，改动就整体搬过去了。如果改动涉及多个文件且部分文件在 dev 上也被改过，可能会冲突，用前面 stash 冲突的处理思路解决即可。
情况二，改动已经提交在 master 上了。这时候不要试图"把提交移过去"这种思维，而是用 cherry-pick 来实现目标。先 git log 找到那个提交的 hash，然后 git checkout dev，再 git cherry-pick <hash>，Git 会把那个提交的改动在新的分支上重新应用一遍。如果 master 上那个提交是你独有的、还没有别人基于它开发，master 分支本身也要处理掉这个提交，可以用 git reset --hard HEAD~1 抹掉（前提是 master 没有被推送，或者推送了但你能确定别人没拉过）；如果已经推送且可能被别人使用，那就不要 reset，让那个提交留在 master 上，或者用 git revert 生成一个反向提交抵消它。
顺便把两个看着像的术语说清楚：cherry-pick 是把某个提交"挑"到当前分支，fetch 是把远端仓库的引用和对象拉下来，两者完全不是一回事。网上有人问"git pick 和 fetch 有什么区别"，多半是把 cherry-pick 简写成了 pick，这里一并说明。
4.2 commit --amend 的正确使用场景和禁忌
commit --amend 是任务切换场景里经常顺手用到的命令，它的作用是把当前分支最近一次提交替换成新提交，也就是修改上一次提交的内容或提交信息。
什么时候该用？比如你刚 commit 完，发现漏了一个文件；或者提交信息写错了；或者想把上一次提交里的一段调试代码去掉。这时候 git add 需要的文件，然后 git commit --amend 就行，不会产生一条新的提交记录。
什么时候绝对不能用？提交已经推送到共享分支、并且可能被其他人拉取的时候。因为 amend 会生成一个新的提交对象，原来的提交就被替换了，别人如果基于旧提交开发，pull 的时候会直接冲突，而且这种冲突非常难解。我的经验是：commit --amend 只对"还在自己本地、绝不推送"的提交使用。一旦推送过，老老实实再提交一条新 commit，或者用 revert，别贪图历史的干净去动已公开的历史。
4.3 已推送的错误提交，revert 才是正规操作
任务切换的时候，最怕的就是"手一抖把测试代码推到了公共分支"。这种场合下，git reset --hard 是把分支指针往回拨，但公共分支上别人已经拉过这个提交怎么办？你的本地 reset 了，别人那里还是旧状态，下一次 pull/push 又是一场灾难。
正规做法是 git revert <hash>，它不会删除历史，而是生成一个与目标提交相反的新提交，把代码状态还原。好处是历史线性推进、所有人都能正常同步，坏处是提交记录里会多出一条 revert 记录——这是完全可以接受的代价。
我在实际项目中见过不少人把 revert 和 reset 搞混。一句话总结：从未推送、只有你自己的分支，用 reset 随便玩；已经推送、可能被共享的分支，用 revert。这个原则在任务切换场景里尤其重要，因为切换时你往往手忙脚乱，更容易把"我以为推的是自己分支"变成"实际推到了公共分支"。
5. 任务切换路上的高频翻车现场与完整排查链路
5.1 SSH 认证失败：从报错到定位的完整排查
任务切换免不了要频繁 clone、push、pull，SSH 认证失败几乎是所有人都会撞上的墙。报错信息通常是 Permission denied (publickey)，或者 Host key verification failed。
我的排查链路是固定的。第一步，ssh -T git@github.com（换成你的托管平台地址）测试连通性，看是不是认证问题。第二步，如果提示 publickey，用 ssh -vT git@github.com 看 verbose 输出，确认客户端实际尝试了哪些 key 文件。第三步，检查 key 是否在正确位置，默认是 ~/.ssh/id_ed25519 或 id_rsa，如果换过机器或者重新装过系统，私钥很可能不在。第四步，确认密钥是否被 ssh-agent 加载，ssh-add -l 查看，没有就 ssh-add 一下。第五步，如果以上都没问题，检查 ~/.ssh/config 里有没有乱七八糟的配置，比如某个 Host 被指向了错误的 IdentityFile 或者多余的命令段。
我遇到过的最隐蔽的坑是：本机装了某个需要修改网络配置的工具之后，~/.ssh/config 里被加了一段针对 git 域名的额外命令配置，导致 Git 的 SSH 请求全部走了错误通道，报错又臭又长，完全看不出来和本地网络设置有关。处理方式是直接编辑 config 文件清理掉那些不是你自己写的段落。排查之后记得把 key 的公钥更新到托管平台的 SSH keys 设置里，这个步骤经常被新人漏掉。
5.2 clone 一直连 127.0.0.1 的 7890 端口：本地转发配置残留的坑
如果你 clone 的时候报 git clone failed to connect to 127.0.0.1 port 7890: connection refused，先别怀疑网络。这个报错的意思是 Git 尝试通过本地 127.0.0.1:7890 这个地址去建连，而那个端口上根本没有服务在监听。
最常见的原因是环境变量或全局配置里残留了本地转发设置。Git 默认会读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 这几个环境变量，也会读取 git config 里的 http.proxy / https.proxy。某些网络调试类工具（比如本地端口转发、抓包调试类的软件）在安装或使用时会写这些设置，等你关了工具或者切了网络，配置还留着，Git 就傻乎乎地往那个死端口上撞。
排查命令顺序如下：先 env | grep -i proxy 看环境变量；再看 git config --global --get http.proxy 和 git config --global --get https.proxy。找到残留后，git config --global --unset http.proxy，环境变量的话在当前终端里 unset，Windows 上则去系统环境变量里删掉。如果是某个仓库局部配置的问题，把 --global 去掉，在仓库目录里单独 unset 即可。
5.3 CRLF 换行符警告：Windows 和 Linux 之间的老冤家
在 Windows 上开发、代码最终要部署到 Linux 服务器的项目里，每次切换分支、commit 都会看到 warning: LF will be replaced by CRLF 之类的警告。原因很简单：Windows 用 CRLF 换行，Linux/macOS 用 LF，Git 在 checkout 的时候会按配置自动转换，转换规则的设置不对，就会产生"改了文件但看不出改了哪一行"的诡异 diff，甚至让 merge 产生毫无意义的冲突。
这里我和大多数人的建议一致：统一用 LF 作为仓库内存储格式。Git 配置上，core.autocrlf 建议在 Windows 开发机上设为 true（checkout 时转成 CRLF 方便编辑器），在 Linux/macOS 上设为 input 或 false。更稳妥的做法是在仓库根目录放一个 .gitattributes 文件，明确声明文本文件的换行符策略，比如 * text=auto、*.sh text eol=lf 这类规则，这样不管谁在哪台机器上操作，行为都一致。
任务切换场景下还有个小提醒：如果你刚配置完 autocrlf，切到一个历史久远的分支，可能会看到一堆"整文件被修改"的 diff，这不是你改的，是换行符在洗牌。这时候别急着提交，先用 git diff --ignore-space-at-eol 之类的参数看清楚真正的改动。
5.4 提交大文件失败与 .gitignore 没起作用的真相
git 无法提交大文件 这个问题，我在群里见过无数人问。报错要么是本地的 fatal: The file will be larger than the maximum allowed size，要么是远端仓库直接拒绝推送。大文件本身就不该进 Git 仓库，二进制、压缩包、模型文件这些东西，体积大且没有文本 diff 的意义，放进历史里会让仓库无限膨胀，clone 越来越慢。解决办法是引入 Git LFS 管理大文件，或者在设计阶段就把大文件放到对象存储、NAS 等外部位置，仓库里只存引用信息。
至于"git 的过滤文件没有作用"，绝大多数情况不是 .gitignore 失效，而是那个文件早就被 Git 跟踪了。.gitignore 只对"尚未被跟踪"的文件生效，一个文件只要曾经被 git add 过、进过历史，之后再怎么写 .gitignore 都拦不住它的更新。正确的收尾方式是 git rm --cached <file> 把它从索引里移除（注意 --cached 只删索引不删工作区文件），提交之后再配合 .gitignore 防止重新加入。任务切换时最容易犯的错就是把"某个文件之前被提交过"这个事实忘了，导致在新分支里写了过滤规则却毫无效果。
6. 从"勉强拿捏"到逐渐顺手：我沉淀下来的切换流程
6.1 每个任务一个分支，切换前固定五步
经过长期的折腾，我现在每次任务切换都走固定的五步，顺序基本不变。第一步，git status 看一眼现场，确认要保留什么。第二步，有价值的改动要么提交成 WIP 分支要么入 stash 并写明消息。第三步，git fetch origin 刷新远端状态，确认目标分支的结构。第四步，如果只是快速看两眼就切回来，用 checkout + stash；如果要长期并行，就直接加一个 worktree。第五步，切换完成之后，git log --oneline -5 和 git branch --show-current 双重确认自己现在到底在哪个分支、哪个位置。
这套流程看起来简单，但每一步都是在防止特定的翻车。比如很多人切完分支根本不确认自己在哪里，凭感觉 commit，最后把代码提交到了错误分支，产生了一条"游离"的提交，只能靠 cherry-pick 去补。我在自己项目里见过这种 commit 最后变成历史上一段莫名奇妙记录的次数，实在太多了。
6.2 两个让我少踩不少坑的小习惯
第一个习惯是配置常用别名。git config --global alias.lg "log --oneline --graph --all --decorate"，git lg 一眼看清分支结构；git config --global alias.st "status -sb"，快速看状态。任务切换时能少敲一半命令，也能少一大半输错命令的机会。
第二个习惯是每个任务开工之前就把分支名想好，不要用 fix、dev、test 这种让人猜不出内容的命名。我个人的命名规则是 类型/任务号-简述，比如 feature/TASK-1024-order-module、hotfix/TASK-1023-login-redis。这样切换回来的时候，git worktree list 或 git branch 一列，马上就知道每个分支在干什么，不用靠记忆。
6.3 关于 Git Bash 的碎碎念
最后补充一个所有 Windows 用户都会遇到的细节：在 Git Bash 里复制粘贴和平时习惯不一样。默认 Ctrl+C 是中断，Ctrl+V 也不会粘贴。我的做法是：复制用 Ctrl+Insert，粘贴用 Shift+Insert，或者用鼠标右键菜单。刚开始可能不习惯，但一旦形成肌肉记忆，效率差别很明显。
另外，如果你在 Git Bash 里执行某些命令时遇到 git open /dev/null or dup failed: no such file or directory 这种怪报错，通常是当前终端环境的管道或标准输入输出被某种方式搞坏了，最常见的是在脚本里用了奇怪的重定向，或者是终端软件本身的兼容问题，换一个干净的终端窗口、重新打开 Git Bash 一般就能解决。
说到底，Git 任务切换这件事，从来不是靠背命令解决的，而是靠一套适合自己的流程和纪律。我从最开始的手忙脚乱，到现在的勉强拿捏，最大的改变就是不再依赖"临场反应"，而是把每个场景的应对方式都提前想好了。你可以先照着上面的流程跑一跑，再根据自己的项目节奏调整。等你哪一天发现自己切换任务不再冒冷汗了，那才算真正把 Git 用顺了。