在版本控制工具里，Git 能长期占据主流位置，靠的就是分支这套设计。要说使用方法，创建与切换分支根本算不上高深操作，但我在带团队和实际写项目的过程中发现，绝大多数协作事故——覆盖了别人的改动、把代码提交到错误分支、分支删了找不回来——都恰好发生在这些看起来“最基础”的命令上。所以这篇文章就围绕 Git 创建与切换分支展开，先把分支在版本控制里到底扮演什么角色讲清楚，再把我平时开分支、切分支、合并清理的一整套操作习惯摊开，最后附一份我踩过坑之后整理的避坑清单。适合刚把 commit、push 用熟、准备进入多人协作阶段的开发者，也适合那些天天用 Git、但想把分支逻辑系统梳理一遍的老手。
1. 先理解分支：版本控制里的“平行世界”
1.1 分支解决了协作中的什么痛点
如果没有分支，所有人在同一条提交历史里往前走。你写了一半的功能，别人一 pull 就拿走了你尚未完成、甚至跑不起来的代码。更麻烦的是，A 同学改的登录模块和 B 同学改的支付模块，如果都堆在同一条线上，一旦要单独上线其中一个，根本没法拆分，只能把没做完的东西一起带到生产环境。
分支的核心价值可以压缩成三个词：隔离、实验、可控发布。隔离让不同任务之间的风险互不传递，你做你的搜索优化，我做我的支付超时处理，即便一边做砸了也不会污染另一边；实验让大胆的改动可以随时随地开了又删，不用怕影响主流程；可控发布让主干始终保持可上线状态，CI 里验证的东西不会因为某个人的半成品而变红。
注意：分支不是用来“珍藏代码”的，而是用来“隔离风险”的。一个分支如果长期存在又不合并，本质上是在积累技术债。
1.2 从“指针”理解分支的本质
Git 的提交不是简单的一串递增版本号，而是一条通过 parent 指针串起来的链表。每次 commit 都会生成一个四十位十六进制的哈希值，这个哈希里既包含这次改动的完整快照，也包含前一个提交的哈希。所以整条历史可以理解成这样：
C1 <---------- C2 <---------- C3 <---------- C4(当前所在提交)分支名，本质上是“一个指向提交对象的可移动指针”。新建分支时，Git 并不会把仓库里的代码复制一份，真正发生的只是在当前提交上再贴一个标签。这也是为什么 Git 创建分支极其廉价——它不是一个文件拷贝动作，只是多写了四十来个字节的引用信息。
还有一个关键角色是 HEAD。HEAD 是一个特殊指针，表示“我现在站在哪个分支上”。注意它的指向链路是：HEAD 指向分支名，分支名再指向提交。所以切换分支，说穿了就是两件事：把 HEAD 从分支 A 挪到分支 B，然后再把工作区里的文件同步成分支 B 对应的内容。
切换前：HEAD -> main main 指向 C4 切换后：HEAD -> feature feature 指向 C4你不需要把这里面的每个概念都背下来，但“分支是指针、HEAD 是指向分支的指针”这个认知，能帮你后面理解为什么有些切换会被拒绝、为什么删了分支还能恢复。
1.3 什么时候该开分支，什么时候不该开
开分支的判断标准其实很简单：这个任务能不能独立上线？能不能独立回滚？需不需要多人协作？如果答案里有一个“是”，就应该开分支。
我的个人习惯是：改动半小时就能完成、今天就要合回主干的小事，不单独开分支；但只要任务周期超过一天、或者要动多个文件，基本无脑开分支。还有一类情况必须开分支——主干被保护，不能直接 push。这种情况下开分支不只是习惯，而是规矩。
反过来，也不建议为了开分支而开分支。一个做了两天就废弃的分支，挂在那里只会让分支列表越来越长。主分支永远保持可用状态，功能分支按需创建、合并即删，这比任何花哨的 Git Flow 都更实在。
2. 创建分支：从命令到命名规范
2.1 三类创建方式与适用场景
创建分支看似只有一条命令，实际有几种常见写法，区别只在“要不要顺手切过去”。先把结论放这：
| 命令 | 行为 | 适用场景 |
|---|---|---|
git branch feature/login | 只创建，不切换 | 批量建分支、脚本中建分支 |
git checkout -b feature/login | 创建并切换 | 老版本习惯，兼容旧脚本 |
git switch -c feature/login | 创建并切换 | 日常开发推荐，语义清晰 |
为什么不推荐日常用checkout -b？因为checkout这个命令身兼数职——切分支、恢复文件、创建分支全挂在同一个命令名下。尤其在旧版本里，当你敲git checkout feature/login，如果当前目录恰好存在同名文件，Git 可能按“恢复文件”的逻辑去处理，行为经常让人摸不着头脑。switch是 Git 2.23 开始引入的专责命令，只负责切换和创建分支，语义单一，报错信息也更直接。
# 日常开发最常用的一行 git switch -c feature/payment-timeout2.2 从一个指定起点创建分支
大多数人以为分支只能从“当前所在位置”创建，其实起点完全可以指定。这在追查历史 bug、基于远程分支开发时非常有用。
# 从某个历史提交出发 git switch -c fix-old-bug 3f2a9b1 # 基于远程某个分支创建本地分支 git fetch origin git switch -c feature/login origin/feature/login # 基于某个 tag 创建发布分支 git switch -c release-1.0 v1.0.0这里有个高频坑：很多人以为“从 main 创建分支”等于“基于远程最新 main 创建”，但如果你本地 main 已经过期，创建出来的分支起点其实是旧的。正确做法是先git switch main && git pull，或者直接以origin/main为起点创建。
提示：从远程跟踪分支创建本地分支时，新版 Git 会自动建立 upstream 跟踪关系。如果没自动配对，用
git branch --set-upstream-to=origin/feature/login feature/login手动补上，否则后面 push 还要多敲参数。
2.3 分支命名规范：团队协作的第一道约束
分支名是写给三个月后的自己看的技术文档。你当然可以随手叫test、1111、final最终版，但混乱的命名会直接拖垮协作效率。我建议按前缀区分任务类型，一套简单的约定就够：
| 前缀 | 用途 |
|---|---|
feature/ | 新功能开发 |
bugfix/ | 常规缺陷修复 |
hotfix/ | 线上紧急修复 |
release/ | 发布准备与版本收敛 |
docs/ | 文档调整 |
chore/ | 依赖、配置、构建等杂务 |
命名规则记住几个要点：全小写，短横线连接单词，不要用下划线；名字要有语义，一眼看出在做什么；不要用纯日期、不要用无意义的数字序号。
为什么前缀规范这么重要？因为 Git 支持按通配符过滤分支：
git branch --list 'feature/*' git branch --list 'bugfix/*'这一条就能把几十个分支按类型筛出来。CI 流水线也可以按命名空间触发不同的构建策略，比如feature/只跑单元测试，release/额外跑集成测试，这些都是在命名规范之上长出来的能力。
3. 切换分支：会切也要会处理现场
3.1 切换分支时 Git 到底做了什么
很多人以为切换分支只是“换了个名字”，其实 Git 在背后做了一整套动作：先把 HEAD 的指向切到目标分支；再把工作区和暂存区里被跟踪的文件，替换成目标分支对应提交的内容；同时保留那些未被跟踪的新文件。
这个流程就是为什么你经常会遇到“切不过去”的情况。比如你在 main 上改了某个文件，而这个文件在目标分支上的内容和当前内容不同，Git 担心切换后你的改动会被无声覆盖，就会直接拒绝，并报出类似这样的错误：
error: Your local changes to the following files would be overwritten by checkout: src/api/user.js Please commit your changes or stash them before you switch branches.这是保护机制，不是 Git 抽风。搞清楚这一点，后面所有“切换不了”的问题都能迎刃而解。
3.2 带着未提交改动切换的三种选择
遇到切换被拒，根据改动价值，有三种处理办法：
| 现场情况 | 建议动作 | 什么时候用 |
|---|---|---|
| 改动已完成，本来就属于当前分支 | git add+git commit | 提交完再切，最干净 |
| 改动还没做完，只是临时想切走 | git stash push -m "说明" | 切完随时stash pop取回 |
| 改动彻底不要了 | git restore <file> | 确认是废稿才用 |
stash是处理“临时切换现场”最常用的工具。它会把当前工作区里已跟踪的改动（含已暂存和未暂存）打包存进一个栈，让工作区恢复干净，之后用git stash pop把改动取回来。
# 暂存当前改动 git stash push -m "登录模块未完成" # 切到另一个分支做事，回来后恢复现场 git stash pop用 stash 有几个小细节：默认它不包含未跟踪的新文件，想连新文件一起收起来用git stash -u；多次 stash 之后一定要写备注，不然过几天看git stash list根本分不清里面是什么；pop之后如果目标分支已经有改动，可能触发冲突，需要手动解决，这属于正常现象。
如果说 stash 是把现场“收起来”，那restore就是直接“扔垃圾”。注意区分：只丢弃未暂存的修改，git restore <file>就够；如果改动已经git add进了暂存区，需要git restore --staged --worktree <file>。还有一个旧命令git reset --hard能一次性还原全部，但会把未提交的改动全部丢掉，我用之前都会再三确认。
3.3 在 checkout 与 switch 之间做选择
前面说了 switch 语义更干净，这里再补几个日常非常好用的细节。git switch -可以快速回到上一个分支，这个操作我在 review 代码、来回比较分支时几乎离不开；git switch -m则可以在切换时把当前改动直接带到目标分支，适合改动“应该属于目标分支”但已经写了一半的情况，不过有触发冲突的风险，要准备好解决冲突。
checkout也不是一无是处，老脚本里到处都是checkout -b，没必要强行改写。只是新项目、新习惯，我建议一律用switch。类似地，恢复文件用的restore也是新命令，比checkout -- <file>语义清晰得多。工具新旧不重要，重要的是每个动作意图明确，减少误操作空间。
4. 分支的查看、对比与合并评估
4.1 查看分支状态的三板斧
切换和创建都不难，难的是知道自己仓库里现在是什么局面。我每次开工前，至少跑一遍这三个命令：
# 本地加远程全部分支 git branch -a # 带跟踪关系、领先/落后数量 git branch -vv # 看哪些分支已经合并、哪些还没合并 git branch --merged git branch --no-mergedgit branch -vv的输出信息量很大，每一行包含分支名、当前指向的提交、上游分支、以及领先多少提交、落后多少提交。比如看到feature/pay [origin/feature/pay] ahead 2, behind 1，就知道本地比远程多两个提交，远程又有一个本地没有的提交，需要先 pull 再 push。
再分享一个偷懒技巧，把常用的复杂命令配成别名：
git config --global alias.br "branch -vv" git config --global alias.tree "log --oneline --graph --all --decorate"配置完后，git tree可以直接看整个仓库的提交图形，分支走向和合并点一目了然，比任何 GUI 都直观。
4.2 合并前如何评估差异
合并之前一定要先看一眼“到底要合什么东西进来”。两条命令被我用了无数次：
# 看 feature 分支独有的提交 git log main..feature # 看 feature 相对分叉点改了什么 git diff main...feature这里说明一下两点和三点的问题。git diff main..feature比较的是 main 和 feature 两个端点直接的差异；而git diff main...feature（三个点）会先找到 main 与 feature 的共同祖先，再比较祖先与 feature 的差异，所以只显示本分支从分叉点之后引入的改动。评审场景，我基本都用三点形式，避免看到一堆原本就存在的老代码差异。
配合提交信息的规范，评估会非常快。如果 feature 上的每个提交都小而聚焦，看个三五条 commit message 就知道这次改动干了什么；如果合并请求里混着“改登录”、“调样式”、“升级依赖”三种无关改动，那不管代码质量多高，都值得先拆分再合并。
4.3 快进合并与保留合并记录
合并的核心动作很简单：先切到目标分支，再执行 merge。
git switch main git pull git merge feature/payment-timeout这里有一个必须理解的概念——fast-forward。如果 main 从分支点之后没有任何新提交，Git 不会生成新的提交节点，而是直接把 main 指针向前推进到 feature 的位置，这就是快进合并，历史呈线性。如果 main 也动了，两个分支产生了分叉，Git 就会做一次三方合并，生成一个包含两个父提交的合并提交。
分叉场景示意： main: C1 ---- C2 ---- C3 feature: C1 ---- C2 ---- C4 合并后： C1 ---- C2 ---- C3 ---- M / C4 --在多人协作项目里，我倾向于用git merge --no-ff feature/login强制生成合并提交。它的好处是：保留“这条功能是什么时候作为一个整体进来的”这个信息，哪怕功能本身只是几个提交的集合，后面想整体回退也容易定位。代价是提交图上会多出一些合并节点，这在我看来完全值得。
至于 rebase，它可以让合并前历史保持线性：在 feature 分支上执行git rebase main，把本分支的提交一个个重放到 main 顶端，然后再合并就是快进。但注意，rebase 会重写提交历史，只建议用于还没推送出去的个人分支。一旦分支被多人共享，rebase 会造成别人的本地历史和你这边不一致，这是团队里最容易引发事故的操作之一。
5. 本地分支与远程分支的完整联动
5.1 第一次推送要做的关联动作
在本地把分支开发完，第一次推到远程时，大多数人会用两个命令：
git push -u origin feature/payment-timeout-u的全称是--set-upstream，意思是给本地分支设置上游跟踪分支。做一次这个动作之后，后续的git push和git pull都不用再写远程名和分支名，Git 会自动找到对应的远程分支。
配合git branch -vv查看，关联成功的分支会显示成类似这样：
* feature/payment-timeout 5f0a2c3 [origin/feature/payment-timeout] fix timeout param方括号里就是上游分支，后面还能看到领先/落后数量。如果没有关联，push 时 Git 会提示你使用--set-upstream，说明这一步还没做。还有一种情况是同事已经建了同名远程分支，你想接过来继续开发：
git fetch origin git switch -c feature/payment-timeout origin/feature/payment-timeout如果本地不存在同名分支，而远程只有一个匹配分支，直接git switch feature/payment-timeout也能自动创建并建立跟踪关系，这是 Git 的 DWIM 机制，日常用起来非常顺。
5.2 拉取、清理与远程分支的同步
远程分支被同事删掉之后，本地执行git branch -a经常还会看到一条粉红色的远程分支记录，这是因为本地缓存的远程引用没有同步。用git fetch --prune可以清理掉这些已经消失的远程分支引用，或者单独执行git remote prune origin。
我建议把 fetch 加 prune 养成肌肉记忆：
git fetch --prune origin这一步成本极低，却能避免你对着一条早就该消失的远程分支发呆，也能防止基于过期引用创建出错误的新分支。很多人 pull 之后发现“被我删除的分支又出现”，多半就是本地引用没清理。
5.3 合并之后的分支清理艺术
分支的价值在合并那一刻兑现，合并之后它的使命就结束了。我见过太多团队，feature 分支合并了半年还挂在列表里，越积越多，最后没人敢删。实际上正确姿势非常简单：合并完，切回主干，删除本地分支，再删除远程分支。
# 一个完整的分支生命周期 git switch main git pull git switch -c feature/payment-timeout # ...开发、提交若干次... git push -u origin feature/payment-timeout # ...请求合并、评审、合并... git switch main git pull git branch -d feature/payment-timeout git push origin --delete feature/payment-timeout这里用-d而不是-D。-d是安全删除，Git 会检查分支是否已被当前分支合并，如果没合并会拒绝删除并提示；-D是强制删除，不管有没有合并都会删。
注意：删除是廉价的，重建也是廉价的，唯独“删完之后发现没提交记录”的恢复成本很高。所以强删之前，务必确认分支里的内容已经合并，或者已经被你把关键提交复制到别处。
6. 常见问题与避坑速查
6.1 切换被拒绝：未提交改动如何处理
这是最经典的报错，原因就是前面讲过的切换机制。根据改动的去向，我平时按这个顺序处理：
先判断改动是不是已经没用了。确定没用了，git restore收拾掉；改动还有用但不想提交，git stash push -m "说明"暂存现场；改动已经完成，而且恰恰应该放到当前分支上，直接提交再切换。
还有一个进阶场景：改动其实是做了一半、但你已经确定它属于目标分支，可以用git switch -m feature/login带着改动切过去。Git 会把当前改动合并进目标分支的工作区，如果两边改了同一处代码，就会产生冲突，需要手动解决。这个操作适合熟练工，新手建议老老实实走 stash。
6.2 误删分支能不能恢复
先说结论：大概率能，但时间越快成功概率越高。当你git branch -D old-feature之后回过神来，第一件事就是跑git reflog。
reflog 是 Git 的“操作日志”，记录 HEAD 每一次移动的历史。即使分支引用被删了，只要之前 checkout 过这个分支，HEAD 的 reflog 里大概率还留着它最后指向的提交哈希。找到那个哈希之后：
git switch -c old-feature 8c3f1a2这样就基于那个提交把分支重新建回来了。如果你是刚提交完就误删，连工作区内容都还在，恢复几乎没有损失。如果那个分支从来没被 checkout 过，reflog 里可能找不到，可以试试git fsck --lost-found找悬挂提交，但这就是撞运气了，因为悬挂对象可能在 gc 时被清掉。
所以我有条实操经验：哪怕功能还没做完，也尽早git push -u推到远程一次。远程分支就是最保险的备份，本地哪怕全删了，从 remote 拉回来也就几分钟的事。
6.3 游离态与脱离分支的提交
detached HEAD 翻译过来就是“游离的 HEAD”，指 HEAD 不再指向某个分支名，而是直接指向一个提交对象。进入这个状态通常是执行了这类命令：
git switch --detach 3f2a9b1或者老旧的git checkout <commit-hash>。为什么说这是坑？因为在这里提交的新 commit 没有任何分支引用它，一旦切回别的分支，这些提交就处于“悬空”状态，随时可能被 gc 清理掉。
危险操作现场是这样的：你在游离状态改了代码并提交，然后忘记创建分支就直接切回 main，几小时后想起来，用 reflog 还能翻出来，但再过几天可能就真没了。正确的挽救姿势是：
# 发现自己在游离状态，立刻用分支把当前提交接住 git switch -c rescue-branch git switch main git merge rescue-branch先建分支保住提交，再合回主干，一步到位。判断自己是不是游离态很简单：git status输出里如果不显示“On branch xxx”，而是在第一行写“HEAD detached at 3f2a9b1”，就要留神了。
6.4 分支越来越多，怎么系统清理
分支一多，最有效的治理方式不是定期“大扫除”，而是建立“合并即删”的默认习惯。每次合并完一个功能，顺手把本地和远程分支都删掉，全程不到十秒。如果你用代码托管平台提合并请求，也可以在那边配置“合并后自动删除源分支”，直接把这一步自动化。
如果仓库里已经积累了大量旧分支，先分辨哪些能安全清理：
# 列出已被合并到 main 的分支，基本都能删 git branch --merged main # 看哪些分支还没被合并，逐个判断 git branch --no-merged main注意--merged列出的分支可能包含 main 自己，用grep -v排除即可。安全起见，清理动作之前先git fetch --prune，把远程引用刷新一遍，避免因为本地引用太旧而误判。
最后说点个人体会。分支操作真正难的不是命令，而是习惯。我每次开始一个新任务，都会先花三十秒确认自己站在哪个分支、起点是不是最新；做完一个阶段性改动，第一反应不是急着 push，而是切回主干看一眼 diff；合并之前，先确认分支是不是基于最新主干。这些小动作加起来，比任何花哨的 Git 技巧都值钱。还有一个用了就回不去的小技巧：git switch -可以快速回到上一个分支，我在日常 review 和来回比较分支时几乎离不开它。希望这篇分支创建与切换的梳理，能帮你少踩几个我当年踩过的坑。
