1. 切分支这么多年你真的知道切的是什么吗git checkout dev或者git switch dev应该是大部分开发者每天敲得最多的命令之一。但说实话很多人用了两三年 Git对切换分支的理解还停留在把当前代码变成另一个分支的样子这个层面。我自己就吃过亏有次改了一堆本地代码随手切到另一个分支处理紧急 bug回来发现改动全没了整个人直接懵了。后来才搞明白改动不是丢了而是被分支切换的机制挡住或藏起来了。先明确一个前提Git 里的分支本质上不是文件夹也不是目录快照它只是一个指向某次提交的指针。而你当前在哪个分支上工作完全由HEAD这个指针决定。理解这一点再看一切分支操作都会通透很多。1.1 分支不是目录HEAD 才是你的当前坐标很多刚接触 Git 的同学会把分支理解成我的一套代码文件。这个理解不能说全错但它会误导你让你以为切换分支就是在多个代码目录之间来回跳。实际上你的电脑上始终只有一份工作目录里面存的永远是当前分支最近的提交内容。Git 内部是这样组织的分支一个轻量的、可移动的指针指向某次提交commit。HEAD指向你当前所在的分支。HEAD - dev说明你正在 dev 分支上。工作区Working Tree你肉眼看到、正在编辑的文件。暂存区Index / Stage你执行git add之后、还没git commit的中间状态。切换分支的操作底层可以理解为三步把HEAD从当前分支移动到目标分支。检查工作区和暂存区是否会影响切换后面详述。用目标分支最后一次提交的内容去同步工作区的文件。所以你看切换分支不是换了个文件夹而是在同一个文件夹里把内容照着另一个分支的样子重新布置一遍。这也就解释了为什么切换分支时工作区里有些文件会变、有些不会变——因为目标分支和你当前分支的内容差异决定了哪些文件需要更新。1.2 三棵树模型为什么 Git 切换前要查户口Git 官方文档里有个非常核心的概念叫三棵树HEAD当前提交、暂存区、工作区。切换分支时Git 要做的事情是在这三者之间做一致性检查说白了就是——确认你的工作区和暂存区不会跟目标分支产生冲突。我用一个生活中的类比来解释你把工位上的文件按照项目 A和项目 B两套方案分别归档。现在你从项目 A 切到项目 B理论上只需要换一套文件放上去。但如果你的桌面上还有一份没归档完的草稿而这份草稿在项目 B 里根本不存在或者和项目 B 里已有的文件重名那你就要先决定这份草稿怎么办。Git 的设计原则是绝不让你在没有明确交代的情况下丢失任何工作成果。所以它宁可报错也不会直接覆盖掉你还没提交、还没 stash 的改动。这就是为什么切换分支经常会看到error: Your local changes...这样的提示。1.3 文件为什么会变切换时的同步逻辑理解了上面这些再看为什么切完分支某些文件内容和当前分支长得不一样就顺理成章了。如果目标分支的某个文件和当前分支内容相同切换时文件保持不变。如果目标分支的没有当前分支里的某个文件切换后这个文件会被删除。如果目标分支多出来某个文件切换后工作区会多出这个文件。如果目标分支的某个文件和当前分支内容不同切换时文件会被更新成目标分支的版本。这些行为看上去很简单但实际操作中经常会遇到切完分支我写的代码没了的情况。其实你的代码大概率还在某个提交或者 stash 里只是当前工作区的文件已经同步成了目标分支的版本。搞清楚这个逻辑下面所有的坑你都能自己推断出来。2. 命令行切换分支的标准姿势与常用变体命令行永远是理解 Git 行为的最佳入口。图形工具再方便底层也是帮你拼装命令。所以这一节我不光给你答案还把每条命令背后的适用场景讲清楚。2.1git checkout和git switch新老命令的恩怨情仇如果你查旧教程几乎全是git checkout branch。但从 Git 2.23 开始官方引入了git switch和git restore目的很明确把checkout这个大杂烩命令拆开。git checkout同时承担了两个完全不同的职责切换分支git checkout dev恢复文件git checkout -- file.txt一个命令干两件事容易让初学者混淆。官方于是拆成了git switch专门负责切换分支。git restore专门负责恢复工作区文件。我现在的习惯是新项目新仓库一律用git switch但老项目、公司历史脚本里大量使用checkout你也必须看得懂。两个命令的常见对应关系场景旧命令新命令切换到已有分支git checkout devgit switch dev新建并切换git checkout -b feature/xxxgit switch -c feature/xxx切换到远程分支常见误解git checkout origin/devgit switch origin/dev恢复某个文件git checkout -- README.mdgit restore README.md需要特别提一句git switch origin/dev和git checkout origin/dev一样都会进入游离 HEAD状态后面详细讲所以日常场景里我更推荐先创建本地分支再去切。2.2 新建并切换分支的正确打开方式实际开发里最常用的其实是新建分支 立刻切过去这个组合动作# 旧命令 git checkout -b feature/user-center # 新命令 git switch -c feature/user-center-b和-c都表示 create即创建一个新分支并切换。这里有个容易踩的坑基于哪个提交创建新分支默认是当前 HEAD 所在的提交。所以如果你在 dev 上敲了这条命令新分支会基于 dev 的最新提交创建两个分支的内容暂时完全一样。如果你希望基于别的分支或者某个特定提交创建得先切过去或者用git switch -c feature/user-center origin/main这样创建的新分支会基于origin/main的最新提交。这个用法在多人协作时特别有用——不用本地先切到 main 再 pull 再切回来一条命令搞定。2.3 detached HEAD为什么你会莫名其妙切丢分支这是新人最容易崩溃的场景之一。你在命令行敲了git checkout origin/dev或者git checkout 8e7a2f1然后 Git 提示You are in detached HEAD state.翻译成人话就是你现在不站在任何分支上直接站在某次提交上。这时候你做的任何新提交都不会属于任何分支。一旦你切走这些提交就飘在半空除了通过git reflog还能找回来之外正常的分支列表里根本看不到。为什么说这是个坑因为很多人看到origin/dev觉得这应该就是 dev 分支吧但它其实是远程分支的只读快照直接在它上面改代码、提交是一场灾难。正确的做法是git switch -c dev origin/dev这样会基于origin/dev创建一个本地分支dev并自动建立跟踪关系。或者用更语义化的写法git checkout --track origin/dev这也是我团队里反复强调的看到origin/xxx开头的分支永远不要直接 checkout先创建本地分支再切过去。2.4 从远程拉新分支的完整链路fetch checkout tracking团队协作中同事推了一个新分支你想切换到那个分支上开发。完整链路应该是# 1. 拉取远程最新分支信息 git fetch origin # 2. 查看远程分支 git branch -r # 3. 基于远程分支创建本地分支并切换 git switch -c feature/order origin/feature/order # 4. 验证跟踪关系 git branch -vv只有执行了git fetch你的本地仓库才知道远程新增了哪些分支、哪些提交。很多人直接git switch feature/xxx报错说分支不存在十有八九是忘了先 fetch。git branch -vv会显示本地分支和远程分支的跟踪关系输出类似* feature/order a1b2c3d [origin/feature/order] 实现订单列表 main 9f8e7d6 [origin/main] 更新文档方括号里的内容就是跟踪关系以后你git push、git pull时Git 会自动知道该跟哪个远程分支同步。这也是git switch -c魔法的一部分——它会自动建立跟踪关系省去了手动git branch --set-upstream-to的麻烦。3. 切换失败的真正原因工作区、暂存区和未跟踪文件的处理所有切不过去的报错基本都可以归结为Git 怕你丢代码。这一节我把最常见的三种拦截场景拆开揉碎讲清楚并给出对应的处理方案。3.1 常见报错解读Git 在替你拦什么场景一你改了文件没有提交然后切分支出现error: Your local changes to the following files would be overwritten by checkout: src/App.js Please commit your changes or stash them before you switch branches. Aborting这句报错翻译过来是src/App.js这个文件在目标分支里和当前分支里内容不一样如果强行切换Git 就需要用目标分支的版本覆盖工作区文件而你在工作区做的修改就会被冲掉。所以 Git 选择中止操作。场景二你有一个未跟踪的新文件目标分支里恰好也有同名文件error: The following untracked working tree files would be overwritten by checkout: docs/plan.md Please move or remove them before you switch branches.这说明 Git 发现目标分支的某个文件和你工作区里一个从未被 Git 管理过的文件同名。如果你切过去Git 用目标分支版本覆盖这个文件那你自己写的同名文件就没了。同样是保护机制。场景三你改了文件但目标分支里这个文件没有被改动过这时候 Git 会允许切换并且你本地未提交的修改会原样保留在新分支的工作区里。这是很多人容易忽略的隐藏行为——它不会报错但你会觉得怎么我切了分支改动还在我把三种情况整理成表格方便对照本地状态目标分支中的同名文件切换结果已修改工作区/暂存区与当前分支一致允许切换修改保留已修改工作区/暂存区与当前分支不一致拒绝切换报错未跟踪的新文件存在同名文件拒绝切换报错未跟踪的新文件无同名文件允许切换文件保留理解这张表你就理解了 Git 切换分支时在保护什么它宁愿拦着你也不肯悄悄覆盖你的劳动成果。3.2 stash把半成品挪走的正确姿势当你遇到本地改了代码但还没改完又必须切到别的分支的情况时最安全的做法就是把半成品暂存起来而不是带着它到处跑。# 把当前修改暂存 git stash push -m 订单模块未完成 # 查看暂存列表 git stash list # 切到目标分支处理完再切回来 git switch feature/order # 切回来后恢复暂存 git stash popstash的本质是一个修改栈。你可以暂存多次用git stash list查看用git stash apply stash{1}恢复指定的某一条用git stash drop stash{1}删除某一条。这里有个关键细节git stash默认不包含未跟踪文件。如果你新建了一个文件还没 add直接 stash这个文件会继续留在工作区。想让未跟踪文件也一起暂存需要加-u参数git stash push -u -m 包含新文件的暂存还有一个经常被问到的点stash 恢复时冲突怎么办如果你在两个分支上都改了同一个文件的同一处stash pop时会报冲突Git 会把文件标记为冲突状态需要你手动解决冲突后git add再继续。这跟在分支合并时的冲突处理流程一样不用慌。3.3 未跟踪文件和 .gitignore一个容易被忽略的坑很多人以为未跟踪文件不影响切换分支这句话大体正确但不完全正确。它确实不会阻碍切换除非目标分支里有同名文件见上文场景二。还有一类容易被忽略的文件被.gitignore忽略的文件。这类文件因为压根不进版本管理切换分支时无论怎么切都不会被动。这本来是个好事但如果你没写好.gitignore把本应忽略的node_modules、编译产物、本地配置都提交到了版本库里就可能出现切到另一个分支依赖目录突然消失或者切回来要重新装依赖的诡异现象。我的建议是每个仓库都有意识地维护好.gitignore尤其是node_modules/、dist/、build/、*.local、.idea/这类目录该忽略一定要忽略。很多时候切分支把环境切坏了的锅其实是.gitignore不规范导致的。3.4 两头都要改commit 还是 stash遇到当前分支改到一半另一个分支又急需修改的情况我不建议直接 stash而是先确认当前分支的改动是否已经逻辑完整。如果改动虽然还没测完但代码本身能编译、能跑起来我更倾向于先提交一个带WIPWork In Progress信息的 commitgit add . git commit -m WIP: 订单列表接口开发中这样改动的状态更明确Git 库里有完整记录不会被误清掉。切到另一个分支处理完切回来继续改时再通过git commit --amend修改这条 WIP 提交的说明或者git reset --soft HEAD~1把提交撤回暂存区继续改都行。这里顺便提一嘴git commit --amend它用来修改最近一次提交的说明或内容。很多新人不知道的是amend会生成一个全新的提交对象hash 会变所以千万不要 amend 已经推送到远程的提交否则会被团队同事问候——远程历史和本地历史不一致下一次 push 会强制要求你先 pull而 pull 又可能产生合并分叉。这个知识点跟切分支关系不算直接但切分支前不 commit 的人多了遇到这种问题也就常见了。4. 远程分支切换与多端协作中的那些坑本地分支切来切去只是基本功真实的开发场景里你的对手是远程分支和同事的推送。这一节我把常见协作场景里让人头大的几个点讲透。4.1 本地分支和远程分支的跟踪关系为什么 push 会失败很多新人第一次 push 报了这样的错fatal: The current branch feature/login has no upstream branch. To push the current branch and set the remote tracking branch, use: git push --set-upstream origin feature/login翻译过来就是你当前本地分支没有建立和远程分支的跟踪关系Git 不知道往哪儿推。你需要显式告诉它git push --set-upstream origin feature/login。跟踪关系的作用不光是让git push少打参数它还影响git pull和git status。建立了跟踪关系以后git status会告诉你你的分支领先远程 2 个提交或者落后远程 3 个提交这些信息对日常开发非常有用。查看所有分支的跟踪关系git branch -vv没有上游分支的用[origin/xxx]标记不出来一眼就能看出来问题在哪。4.2 同事刚推了新分支我该怎么切过去场景同事说我推了一个 feature/cart 分支你拉下来看看。你的操作链路应该是git fetch origin git switch -c feature/cart origin/feature/cartgit switch -c会帮你完成三件事创建本地分支、切换过去、建立跟踪关系。三步变一步效率是最高的。如果仓库很大、分支很多git fetch可能比较慢这是正常现象。也可以只 fetch 指定分支减少不必要的通信git fetch origin feature/cart4.3 detached HEAD 再深入为什么会进入这种状态前面提到过git checkout origin/dev会进入 detached HEAD。很多人不理解为什么我切的是分支却变成游离了关键在于origin/dev是一个远程跟踪分支它本质是远程仓库分支在本地的一个只读映射。Git 设计它为一个特殊引用但不允许你直接在上面工作。当你 checkout 一个远程跟踪分支时Git 没有找到同名的本地分支于是直接把 HEAD 指向了那个 commit——也就是进入了不站在任何分支上的状态。避免方法有两个# 首选创建本地分支并跟踪 git switch -c dev origin/dev # 等价做法 git checkout --track origin/dev如果不小心已经进入了 detached HEAD并且做了修改可以用git switch -c new-branch把当前 HEAD 绑定到新分支上这样你做的提交就保住归属了。同样git checkout 某个commit id也会进入 detached HEAD。这种操作通常是为了回头看历史代码或者临时基于某个历史提交做实验。做完实验记得切回分支别一直游离着。4.4 切完分支不干净diff、恢复与误删有时候切完分支你发现某些文件不是自己预期的状态或者跑测试发现少文件。第一步永远是冷静下来先用git status看清当前状态再用git diff看具体差异而不是凭感觉乱操作。如果发现某个文件被改乱了想恢复到当前分支的最近提交状态# 丢弃工作区修改危险操作 git checkout -- src/App.js # 新命令写法 git restore src/App.js需要强调的是restore和checkout --是不可逆的会直接丢弃工作区修改。操作前务必确认这个文件里的改动不是你需要的。我个人的习惯是这种情况下优先用git stash把改动挪走而不是直接丢弃——宁可多留一个备份也别手一抖把半天工作删了。5. 图形化工具里的切换IDEA 与 TortoiseGit 实操并不是所有人都喜欢在命令行里切分支尤其是做前端、测试或者刚上手 Git 的同学图形化工具反而更直观。这里把最主流的两个客户端讲透IDEA 和 TortoiseGit。5.1 IDEA 切换分支右下角的按钮和 Smart CheckoutIDEA 里切换分支最常用的入口是右下角的分支名显示当前分支的那个地方点开后会列出所有本地分支和远程分支选中目标分支再选Checkout即可。还有一个入口顶部菜单VCS - Git - Branches弹出的对话框和右下角一样。IDEA 有一个非常贴心的功能叫Smart Checkout。当你在当前分支有未提交的修改且这些修改跟目标分支有冲突时IDEA 不会像命令行那样直接拒绝而是弹窗提示你是否要执行 Smart Checkout点确认后IDEA 会自动帮你做stash→ 切换分支 →stash pop这一整套流程非常方便。这里有个坑stash pop 如果有冲突IDEA 会打开冲突解决界面你需要手动逐条处理处理完记得让同事帮你 review 一下合并逻辑还是得有人确认。IDEA 里还要注意一个展示问题如果远程仓库里同事新推了分支而你的 IDEA 里看不到需要先在Branches弹窗里执行Fetch或者从VCS - Git - Fetch把远程分支列表刷新出来。否则你大概率会以为同事没推成功。5.2 TortoiseGit 切换Windows 用户的经典选择TortoiseGit 是 Windows 上非常经典的 Git 图形客户端深度集成在资源管理器右键菜单里。切换分支的操作路径是在项目文件夹里右键 -TortoiseGit - Switch/Checkout...弹窗里选择你要切换的分支然后点 OK。这个对话框里有几个关键选项需要注意Branch 单选列表默认列的是本地分支可以勾选All branches查看远程分支。Tag如果你想切到某个标签可以在这里选。Revision这里可以填一个具体的 commit id。Create new branch如果勾选会基于选中的分支/提交创建并切换到一个新分支。TortoiseGit 在切换前同样会检查未提交的改动。如果你有未提交修改而且目标分支有冲突它会弹出提示框让你选择 stash 还是 commit。这里我建议优先选择 stash因为图形界面里 stash 的恢复右键 -TortoiseGit - Stash List还算直观不容易误操作。另外TortoiseGit 显示远程分支时带remotes/origin/前缀例如remotes/origin/dev。新手如果直接选了这个分支同样会进入 detached HEAD 状态。正确做法是在弹窗里选中remotes/origin/dev然后勾选Create new branch并在旁边填一个本地分支名建议就叫dev这样 TortoiseGit 会帮你创建本地分支并绑定跟踪关系。5.3 GUI 工具显示的信息和命令行怎么对应用了图形化工具之后很多人会失去对 Git 底层状态的感知。我建议至少做到能看懂 GUI 操作在命令行里等价于什么GUI 操作等价命令行IDEA / TortoiseGit 的 Checkoutgit switch branchIDEA 的 Smart Checkoutgit stashgit switchgit stash popTortoiseGit 勾选 Create new branchgit switch -c new-branchIDEA 的 Fetchgit fetchTortoiseGit 的 Switch toremotes/origin/xxxgit switch origin/xxxdetached HEAD理解了对应关系哪怕工具界面变了、弹窗文案变了你也能快速推断出它在做什么不会两眼一抹黑。6. 高频场景下的个人习惯与一套稳妥切分支流程最后这部分我不讲大道理直接分享我踩过坑之后沉淀下来的、目前用了三年都没翻车的一套切分支习惯。6.1 我每次切换分支前必做的三件事切分支前尤其是从有大量改动的分支切走时我会严格执行以下三步先git status看清状态。工作区有没有修改、有没有未跟踪文件、处在哪个分支一眼看全。这一步花不了 10 秒但能避免 90% 的切换事故。有修改先决定 commit 还是 stash。改动是完整的功能直接 commit改动是半成品git stash push -u暂存如果手头有急事需要切走而改动又重要到不能丢我甚至会用git diff /tmp/backup.patch再 stash双保险。切之前确认目标分支存在。本地不存在先git fetch再用git branch -r看远程有哪些分支最后才执行切换。这三步下来基本不会出现切过去工作区乱套的情况。6.2 容易让人崩溃的四个瞬间以及补救办法瞬间 1切换分支后本地改动全没了。大概率是被 stash 了或者还在原分支的提交里。先git stash list看看再git reflog看看有没有游离提交。千万不要重新写一遍代码。瞬间 2提示分支不存在但明明同事推了。先git fetch origin刷新远程分支列表再用git branch -r验证。很多 GUI 工具也需要手动 Fetch 才能看到新分支。瞬间 3切过去之后依赖全崩、node_modules 没了。归纳起来就一句话node_modules这种依赖目录就不该被提交到 Git 里。把.gitignore写好彻底清掉仓库里的依赖目录git rm -r --cached node_modules以后就不会出现切分支把依赖切没了的灵异事件。瞬间 4在 detached HEAD 里写了一堆代码。用git switch -c rescue-branch把当前游离状态绑定成一个新分支代码就保住了。然后再考虑怎么合并到正式分支。6.3 保持工作区干净是切换分支的底气说到底切换分支带来的绝大多数问题根源都不是 Git 本身而是工作区太乱。如果你每次切分支前工作区基本是干净的改动要么已提交、要么已 stash那么切换分支就是一条命令的事根本不用想太多。我个人还有个习惯每天开工第一件事不是拉代码而是先看一眼git status和git branch -vv。花一分钟搞清楚我在哪、有没有遗留改动、和远程差了几个提交再开始动手写代码。这个小习惯帮我省了无数不必要的麻烦。最后再分享一个小技巧如果团队有明确规定同一个分支只允许一个人推代码那你在切换分支前最好先看一眼当前分支领先远程几个提交。有时候你本地积累了五六个 commit 没推而同事又往远程推了新代码这时切分支虽然没问题但回来后可能要处理合并冲突。与其被动被冲突砸脸不如在切走之前先把当前分支的代码推到远程把状态清清爽爽地交出去。这样无论切多少次都不会慌。