1. 分支的核心概念与为什么需要分支
1.1 分支的本质：一次提交的指针
很多刚接触 Git 的朋友，最容易在分支这个概念上栽跟头。我最早用 Git 的时候，把分支理解成"代码的副本"，后来才发现这个理解偏差很大。分支本质上就是一个可移动的指针，它指向某一次提交（commit）。
用生活化的例子来类比：你可以把 Git 仓库想象成一本小说的手稿，每次提交就是给手稿拍一张快照，而分支就是贴在某个快照上的书签。你移动书签的位置，不代表你复制了手稿，只是说明你现在关注的是哪个版本的内容。当你基于某个分支创建新分支时，新分支和原分支指向同一个提交，就像同一个快照上贴了两个书签，后续两个书签各自移动，代码才逐渐分叉。
理解了这一点，你就明白为什么 Git 的分支操作非常轻量。创建一个分支不是复制一堆文件，只是新建一个指针，速度极快，几乎不占额外空间。这也是 Git 对比其他版本控制工具的核心优势之一。
1.2 为什么你的工作流离不开分支
分支的价值在于让不同开发任务并行不矛盾。想象一下，你正在开发一个登录功能，突然线上有个紧急 bug 要修。如果没有分支，你只能把手头半成品代码提交上去，或者先藏起来，处理完再恢复。有了分支，你可以从稳定的主分支拉一个修复分支，修完再合并回去，而你的新功能分支可以继续安心开发，两边互不干扰。
我见过很多团队，特别是刚使用 Git 时，所有代码直接往主干上提交。短期看效率很高，但一旦出现线上问题需要回滚，或者两个人同时改同一个文件的同一个位置，立刻手忙脚乱。分支相当于给每个人都划出了一条独立赛道，跑完再汇入主干，这才是团队协作的正确姿势。
还有一个常被忽略的好处：分支给了你"试错"的底气。比如你想尝试一个技术方案，不确定是否可行，拉一个实验分支，随便改，改坏了删掉，对主分支毫无影响。这种心理上的安全感，对开发者来说非常重要。
2. 查看分支：本地、远程与状态判断
2.1 本地分支查看：git branch 与 git branch -v
查看分支是使用 Git 最频繁的操作之一，但很多人只知道一个git branch，实际使用中远远不够。
先看最基础的：git branch列出本地所有分支，当前所在分支会用*号标记出来。比如：
$ git branch dev * master test如果你想知道每个分支最后一次提交的信息，用git branch -v，它会显示每个分支对应的提交哈希和提交说明：
$ git branch -v dev a1b2c3d 完成支付模块重构 * master e4f5a6b 修复登录超时问题 test f6a7b8c 初始化测试框架这里有个实用技巧：加--merged或--no-merged参数，可以筛选已合并和未合并到当前分支的分支。这个在清理分支时非常有用，后面我会细说。
2.2 远程分支与跟踪关系的查看
查看远程分支有两种方式：git branch -r只列出远程分支，git branch -a同时列出本地和远程分支。实际工作中我更推荐git branch -a，因为经常需要对比本地和远程的分支差异。
$ git branch -a dev * master remotes/origin/HEAD -> origin/master remotes/origin/dev remotes/origin/master光看分支列表还不够，你还需要知道本地分支和远程分支的跟踪关系。用git branch -vv可以查看：
$ git branch -vv dev a1b2c3d [origin/dev] 完成支付模块重构 * master e4f5a6b [origin/master] 修复登录超时问题方括号里的内容表示本地分支跟踪的远程分支。如果本地分支领先远程分支若干提交，会显示类似[origin/dev: ahead 2]的提示；如果落后，则显示behind。这个信息对判断代码是否同步非常有价值。
2.3 查看所有分支的提交拓扑：git log --graph
列表形式的分支信息只能告诉你分支存在，却看不出分支之间的关系。想直观地看到分支分叉、合并的历史，必须用git log配合图形化参数：
$ git log --graph --oneline --all * 3f8c9d0 Merge branch 'dev' into master |\ | * 5a6b7c8 优化首页加载速度 | * 2d3e4f5 增加图片懒加载 * | 4c5d6e7 修复用户中心样式问题 |/ * 1a2b3c4 初始化项目这个命令是我日常使用频率最高的命令之一。它能让你一眼看清整个仓库的分支演进脉络，比如哪些分支是从哪里拉出来的、何时合并的、是否存在分叉。建议把alias配置成git lg之类的短命令，提高操作效率。
我自己习惯再加一个--decorate参数，这样分支、标签都会用不同颜色标注出来，信息更完整。
2.4 查看当前工作区状态：git status 与分支的关系
查看分支不只是看列表，更要看当前工作区的状态。git status会告诉你当前在哪个分支、暂存区有哪些文件、工作区哪些文件被修改。每次切换分支之前，一定要先确认工作区是否干净，否则很容易出现代码"凭空消失"的错觉。
一个常见的场景：你在 dev 分支改了文件，没有提交，然后直接切换 master 分支。Git 默认会阻止这个操作，提示你会覆盖本地修改。这时候要么先提交当前分支的修改，要么用git stash临时保存，具体怎么选我后面会详细讲。
3. 创建与切换分支：从基础命令到设计思路
3.1 创建分支的几种方式对比
创建分支最基本的方式是git branch <branch-name>，比如创建 dev 分支：
$ git branch dev这个命令只创建分支，不会切换过去。如果你想创建并立即切换，用git checkout -b <branch-name>：
$ git checkout -b dev或者用新版的git switch -c <branch-name>，语义更清晰，也更安全。git switch是 Git 2.23 引入的命令，专门用于分支切换，把checkout的多重职责拆分了。
还有一个常用需求：基于某个远程分支创建本地分支。
$ git checkout -b dev origin/dev这样会创建一个本地 dev 分支，并自动跟踪远程的 origin/dev 分支。之后git pull和git push就不需要额外指定远程分支了。如果直接执行git checkout dev，而且本地不存在这个分支但远程存在，Git 也会自动帮你创建并跟踪，这个便捷特性很多人不知道。
3.2 切换分支时的工作区处理：stash 的正确使用
分支切不过来，是新手最容易遇到的坑。前面提到过，如果当前分支有未提交的修改，切换分支时 Git 可能会拒绝。此时有三种处理方式：
第一种：直接提交当前修改。适合当前修改已经完成、有意义的场景。
第二种：用git stash暂存。适合手头的活只干了一半，先切过去处理其他事情，回来再恢复。
第三种：强制切换。git checkout -f或git switch -f，这会把当前修改直接丢弃，要谨慎使用，一旦执行找不回来。
git stash是我个人非常喜欢的功能，但要注意它默认不会暂存未跟踪的文件。如果新增了文件，需要用git stash -u才能把未跟踪文件也一起暂存。恢复的时候用git stash pop，它会应用暂存内容并删除暂存记录；如果想保留暂存记录，用git stash apply。
有一次我在 dev 分支改了十几个文件，还没来得及提交，线上出问题要紧急修复。我用git stash -u暂存好，切换到 master 拉修复分支，修完合并，再切回 dev 执行git stash pop，所有改动都齐整整地回来了。这个流程非常顺，强烈建议熟练掌握。
3.3 创建分支的时机与命名规范
什么时候拉分支、怎么命名，直接关系到团队协作的效率。我在实际开发中总结了几条经验：
按功能拉分支：每个新功能从主干拉一个功能分支，功能完成后合并回主干。比如feature/user-login、feature/payment-wechat。
按版本拉分支：发布前从主干拉一个发布分支，比如release/v1.2.0，在这个分支上做最后的测试和修 bug，测试通过后合并回主干并打上版本标签。
按修复类型拉分支：线上 bug 修复单独拉分支，比如hotfix/crash-on-login。
分支命名要见名知义，避免test、new这种含糊的名字。我见过一个项目里有人起名aa、bb这种分支，几天后连他自己都不知道是什么内容了。规范的命名省掉的沟通成本，远超你起名时多花的几秒钟。
3.4 新项目初始化分支的思路
如果你是从零开始一个项目，初始化好主分支后，建议第一时间创建一个 dev 开发分支。日常开发都在 dev 上进行，master 分支始终保持稳定可发布的版本。需要新功能时，从 dev 拉功能分支，开发完成合并回 dev，再定期把 dev 合并到 master 进行发布。
这个流程看起来多几步，但长期维护下来，master 分支永远可用，随时可以回滚，发布新版本也更有底气。
4. 合并分支：fast-forward、三方合并与冲突解决
4.1 合并的两种底层机制：fast-forward 与非 fast-forward
合并分支是 Git 日常操作里技术含量最高的环节，理解它的底层机制非常重要。
Fast-forward 合并：当目标分支（比如 master）从当前分支（比如 feature）拉出后，master 一直没有新的提交，而 feature 有提交，此时把 master 合并到 feature，Git 发现 master 可以直接"快进"到 feature 的最新位置，只需要把 master 的指针移动到 feature 的提交上，不产生新的合并提交。这相当于一条直线上的前进。
$ git merge feature Updating a1b2c3d..e4f5a6b Fast-forward三方合并：如果 master 和 feature 在分叉之后都有了新提交，Git 就需要做一次真正的合并。它会找到两个分支的共同祖先提交，然后对比三个版本（共同祖先、master 最新、feature 最新），把两边各自的改动合并到一起，并生成一个新的合并提交。
$ git merge feature Merge made by the 'ort' strategy.合并完成后，分支拓扑会形成一个分叉点加一个合并点，用git log --graph能看得很清楚。
4.2 merge 与 rebase 的选择
说到合并，永远绕不开merge和rebase的对比。简单说：merge保留历史，rebase重写历史。
merge会创建一个合并提交，完整保留了两条分支的开发历史和分叉点，适合团队协作时保留真实演进过程。缺点是历史可能变得复杂，提交图看多了容易晕。
rebase的操作逻辑是把当前分支的提交"重新播放"到目标分支的最新提交之上，形成一条直线历史。比如把 feature 分支 rebase 到 master：
$ git rebase master执行后，feature 的提交会被重新应用在 master 最新提交之后，看起来就像 feature 是从 master 最新提交开始拉出来的。优点是历史清晰，便于代码审核；缺点是会改写提交哈希，如果分支已经被其他人共用，会带来协作混乱。
我的建议是：本地开发、还没推送的分支，适合用 rebase保持历史整洁；已经推送过、别人也在用的分支，合并时用 merge，不要 rebase，否则容易造成混乱。团队内最好约定统一策略，避免一半人用 merge、一半人用 rebase，最后历史一团乱。
4.3 冲突的产生与解决：从定位到处理
只要两个分支修改了同一个文件，并且修改的位置相邻或重叠，合并时就会产生冲突。Git 会暂停合并，在有冲突的文件里插入冲突标记：
<<<<<<< HEAD 当前分支的内容 ======= 要合并进来的内容 >>>>>>> featureGit 无法判断哪个是正确的，需要你手动决定保留哪部分。解决冲突的正确步骤是：
第一步：用git status查看哪些文件处于冲突状态。冲突文件会显示为both modified。
第二步：逐个打开冲突文件，把<<<<<<<、=======、>>>>>>>这些标记删除，保留你想要的代码。如果两边代码都需要，就把它们合并在一起。
第三步：修改完成后，对冲突文件执行git add，声明冲突已解决。
第四步：执行git commit完成合并提交。如果你用的是git rebase合并，则执行git rebase --continue。
我用过的不少开发者不喜欢解决冲突，总想着让工具自动处理。但实际上，冲突是代码合并的正常现象，特别是多人协作时不可避免。解决冲突的过程，恰恰是理清代码逻辑、发现设计问题的好机会。每次冲突产生，我都会认真核对两边改动，往往能提前发现一些隐患。
4.4 避免冲突的实战经验
冲突虽然正常，但频繁冲突确实影响效率。我在实际项目中总结了几条降低冲突概率的经验：
高频更新主分支：长期开发的分支要频繁把主分支的最新代码合并回来，比如每天上班第一件事git pull origin master，或者用git fetch+git rebase保持同步。分支存活时间越短，冲突概率越低。
保持提交小而专：一次提交只做一件事，改动文件数尽量少。如果一次提交改了十几个文件，和别人的修改撞车的概率就大大增加。
合理拆分模块：代码层面，把公共组件、配置文件等容易被多人修改的内容尽量抽离固定位置，减少多人同时编辑的几率。
使用 git rerere：有一个非常冷门但好用的功能git rerere（reuse recorded resolution），开启后 Git 会记录你解决冲突的方式，下次遇到类似冲突自动帮你解决。我自己在长期维护的项目上一直开着它，确实省了不少重复劳动。开启方式：
$ git config --global rerere.enabled true5. 分支生命周期管理：重命名、删除与清理
5.1 分支重命名的正确姿势
分支从创建到合并，中间难免需要改名。特别是功能发展方向变了，或者名字起得不够直观。
当前分支重命名：
$ git branch -m new-name非当前分支重命名：
$ git branch -m old-name new-name注意，重命名操作只作用于本地，如果分支已经推送到远程，需要先删除远程旧分支，再推送新分支：
$ git push origin :old-name $ git push origin new-name我建议在分支还没推送远端的时候及时改名，一旦推送出去，改名带来的远端同步成本会增加不少。
5.2 分支合并后的删除策略
当一个功能分支完成使命、合并回主分支后，本地分支可以删除了。删除已合并的分支：
$ git branch -d feature-login这里用-d而不是-D，Git 会先检查分支是否已被合并，只有确认合并过才允许删除，防止误删未合并的代码。如果确实想强制删除未合并的分支，用-D，但一定要确认代码是否需要保留。
远程分支的删除：
$ git push origin --delete feature-login删除远程分支是个不可逆的操作，执行前务必确认远程分支的代码已经合并到目标分支，或者不再需要。
5.3 清理本地多余分支
开发时间长了，本地会积累大量无用的分支，一个一个手动删太麻烦。这里说一个我常用的组合命令：
$ git branch --merged master | grep -v 'master\|dev' | xargs git branch -d意思是：列出所有已经合并到 master 的分支，排除 master 和 dev 本身，然后批量删除。
如果你发现本地有些远程已经删除的分支还残留在git branch -a列表里，用以下命令清理：
$ git remote prune origin这会同步清除那些远程已经不存在的分支跟踪记录。如果不确定远程分支状态，先执行git fetch --prune，安全第一。
5.4 基于森林的分支保护
分支操作多了，误删、误推的风险也随之增加。团队协作建议在代码托管平台开启分支保护规则，比如要求 master 分支禁止直接推送，所有变更必须通过合并请求。这虽然不是 Git 本身的命令，但它是分支管理流程的重要一环。
我在自己负责的项目里，都配置了 master 保护：不允许 force push，不允许直接提交，只能通过合并请求合入。这一条规则就能挡住绝大部分误操作。
6. 结合日常开发场景的实战案例
6.1 场景一：从 dev 合并到 test 再发布
这是我被问过最多的问题：开发分支代码如何合并到测试分支？
假设你有一个项目，包含master（生产）、test（测试）、dev（开发）三个长期分支。开发在 dev 完成并自测后，需要合并到 test 供测试人员验证。
$ git checkout test $ git pull origin test $ git merge dev $ git push origin test这几步看起来简单，但有两个细节经常被忽略：
切到 test 之前：确保当前工作区干净，否则git checkout会报错或者把未提交的改动带到 test 分支。
合并前先更新 test：如果 test 分支和远端不同步，最好先git pull，避免在旧版本上合并产生无谓的冲突。
测试验证通过后，要把代码合并到 master 发布，同样按这个流程走一遍。发布完成后，最好再把 master 合并回 dev，保证 dev 包含所有已发布代码。
6.2 场景二：IDEA 等 IDE 中的分支切换操作
不少开发者在命令行用 Git 不熟，习惯用 IDE 的图形界面。以 IDEA 为例，右下角有一个 Git 分支图标，点击就能看到当前分支和所有分支列表，可以快速切换、创建、合并。
但 IDE 的图形界面有时会遮蔽一些细节。比如我在 IDEA 中切换分支时，如果当前分支有未提交的修改，IDEA 默认会提示你选择如何处理，有Smart Checkout（自动 stash 并切换）和Force Checkout（丢弃修改）等选项。很多人不加思考直接选Force Checkout，结果代码找不回去了。
在 IDE 中使用 Git 时，我始终建议时刻关注底部的Git Log窗口，它会显示分支结构和提交历史，比命令行更直观。同时，IDE 的版本更新很快，界面可能有细微变化，但核心的 Git 原理是不变的，理解底层逻辑后，无论界面怎么变都能快速上手。
6.3 场景三：误删分支后找回
分支误删是 Git 使用中最让人崩溃的场景之一。好在 Git 的机制决定了删除分支只是删除了指针，提交对象还悬浮在仓库里，只要知道 commit 哈希，就能找回来。
第一步，用git reflog查看操作历史：
$ git reflog a1b2c3d HEAD@{0}: checkout: moving from feature-login to master e4f5a6b HEAD@{1}: branch: created on feature-login从记录里找到误删分支指向的 commit 哈希，然后基于这个 commit 重新创建分支：
$ git branch feature-login e4f5a6b分支就回来了。这也是为什么我把git reflog视为 Git 的"后悔药"。凡是误操作，先别慌，看一眼 reflog 往往有惊喜。
6.4 场景四：多人协作时保持分支洁净
多人协作时，最怕的就是分支上堆积大量无意义的提交，比如 "fix"、"update"、"test" 这种没有营养的提交信息。合并回主分支后，历史变得非常难读。
我的习惯是：在功能分支本地开发时，频繁提交，但推送前用git rebase -i把多个小提交合并成一个语义清晰的提交。
$ git rebase -i HEAD~3执行后会打开编辑器，把几个提交的pick改成squash，合并成一个。这样推送到远端的分支历史就非常整齐。这个操作只影响本地局部分支，只要这个分支还没被别人使用，就是安全的。
7. 分支操作中的常见错误与排查思路
7.1 分支切换不了：报 "Your local changes would be overwritten"
这个报错的防止思路在前面 stash 部分提过，这里给出详细的排查链路。
第一步：执行git status确认哪些文件被修改。
第二步：确认这些修改是否有意义，是需要提交还是临时保存。
第三步：选择处理方案：
- 修改已完整：
git commit - 修改做了一半：
git stash -u - 修改不需要了：
git checkout -- <file>或git switch -f
我特别提醒一点：不要轻易用git checkout -- <file>，它是从当前分支的最新提交恢复文件，会把该文件的全部本地修改覆盖掉，且无法恢复。必须先确认不要了再操作。
7.2 合并后代码丢失的现象
有开发者合并分支后，发现某些代码"不见了"：明明合并成功了，但某个文件内容还是旧的。
这种情况绝大多数不是 Git 丢失代码，而是合并时选择了某一侧的版本，另一侧的改动被覆盖了。遇到这类情况，用git log --oneline -- <file-path>查看该文件的提交历史，再用git show <commit-hash>:<file-path>查看特定版本的文件内容，对比定位问题。
如果确实需要在合并提交里找回旧版本内容，可以再次手动修改文件，然后提交一次补充修改。Git 不会真正丢失数据，只是需要你仔细检查处理。
7.3 推送被拒绝：non-fast-forward
推送本地分支到远程时，如果提示non-fast-forward，表示远程分支有本地没有的提交，直接推送会覆盖远端历史。
处理方式有两种：
方式一：先拉取远端代码合并，再推送：
$ git pull origin master $ git push origin master方式二：使用 rebase 保持线性历史：
$ git pull --rebase origin master $ git push origin master这两种方式差异在于历史形态，前面 merge 与 rebase 部分已经解释过了。开发分支建议用 rebase 方式，主干分支建议用 merge 方式，团队内部统一约定。
7.4 reflog 的实战价值：所有分支误操作的后悔药
git reflog是 Git 最容易被忽视但最实用的命令之一。它记录了 HEAD 指针的所有移动历史，换句话说，你的每一次 checkout、commit、reset、merge 操作都在里面留痕。
举一个我自己经历过的案例：有一次我在一个分支上做了大量修改，想用git reset回退几个提交，结果参数写错，把分支退回到了很早期的状态，几十次提交看起来都没了。当时团队其他成员已经拉了这个分支的代码，无法简单重做。我靠git reflog找到了丢失提交的哈希，用git branch重新指向恢复，整个过程不到五分钟。
所以我一直强调：所有 Git 训练，第一步应该学的是 reflog，而不是各种高级用法。有了这个"时光机"兜底，很多误操作都不再可怕。
8. 分支管理的最佳实践与个人经验
8.1 适合小团队的分支模型
主流的分支模型有很多，Git Flow、GitHub Flow、GitLab Flow，各有千秋。但对大多数小团队，我强烈建议不要一上来就整套 Git Flow，流程太重反而拖累效率。
一个轻量可落地的方案是：
- master：始终可发布的稳定代码，受保护，只能通过合并请求合入
- dev：日常集成分支，所有开发好的功能先合到这里
- feature/分支*：每个功能一个分支，开发完成后合并到 dev
- hotfix/分支*：线上紧急修复，直接从 master 拉，修完合回 master 和 dev
这套模型的核心理念是"保持简单、但边界清晰"。你不需要引入 release 分支、support 分支这些概念，除非你确实需要同时维护多个在产版本。
8.2 提交信息规范：分支合并的隐形基础
分支合并得再漂亮，如果提交信息一团糟，历史依然不可读。我在项目里推行过一个简单的提交信息规范，效果很好：
- 用动词开头：
Add、Fix、Update、Refactor、Docs - 一句话说明改动意图：
Fix login timeout caused by token expiry - 必要时补充分隔线再写详细说明
遵循这个规范后，即使分支管理偶尔乱了一下，合并记录依然能看明白当时改了什么、为什么改。
8.3 我踩过的分支相关的坑
最后分享几个我这些年真实踩过的坑，希望能帮你避开。
第一个坑：长期不更新本地主分支，然后基于过时的 master 拉分支开发，等到合并时冲突一堆，最后不得不花大量时间解决本来可以避免的冲突。解决方案：拉分支前先 fetch 最新代码。
第二个坑：合并代码时不看git status就推送到远程，结果把合并产生的冲突标记忘在了文件里，导致线上代码直接报错。解决方案：合并后认真检查工作区状态，建议用代码检查工具或 CI 把关。
第三个坑：在一个分支上开发了三个功能，最后合并时发现其中两个还没测试完，无法单独发布。解决方案：一个分支只做一个功能。如果实在分不开，用git cherry-pick挑出需要的提交移植到新分支。
第四个坑：以为git merge失败后分支就废了，急急忙忙重做代码。其实失败后的分支进入 MERGING 状态，执行git merge --abort可以干净地回退到合并前状态，所有代码都在。这是 Git 给的"后悔药"，一定要记住。
8.4 分支操作频率与心理模型
分支用得好不好，很大程度取决于你对它的心理模型。我一直用"书签"这个类比来指导自己做决策：分支只是贴在不同提交上的书签，随时可以创建、移动、删除。有了这个心理模型，你就不怕创建分支、不纠结删除分支，因为你知道真正的数据是提交，分支只是辅助工具。
养成高频小步操作的习惯，性能完全不用担忧，因为 Git 的分支操作成本极低。很多团队分支管理混乱，不是因为技巧不够，而是不敢用分支，或者用得太晚。
8.5 持续学习的方向
分支只是 Git 的核心能力之一。如果你已经熟练掌握查看、创建、合并分支，下一步可以深入cherry-pick（筛选提交）、revert（回滚提交）、worktree（多工作目录并行）等进阶功能。尤其是git worktree，它允许你在同一仓库同时 checkout 多个分支到不同目录，对一个项目需要并行改多个分支的场景非常实用。
Git 的学习是螺旋上升的，底层原理理解得越深，上层命令用起来越从容。祝你在 Git 的分支世界里少踩坑、多产出。
