摘要 ："分支"是 Git 相比于 SVN 最革命性的特性。它让开发者可以同时在不同的工作流中自由切换，互不干扰。很多初学者对分支感到恐惧，觉得"合并"等于"冲突"，冲突等于"灾难"。本篇将用通俗的"平行宇宙"比喻让你彻底理解分支的本质，掌握 git branch、git switch、git merge 和 git rebase，通过刻意设计的冲突场景带你亲历冲突解决全流程。读完后你会爱上开分支的感觉，也会明白那句名言："Git 分支就像呼吸一样轻松。"
一、分支是什么？一个提交图的故事
在上一篇中我们知道，每次 git commit 都会生成一个快照对象，每个对象都包含一个指向其父提交的指针。当我们提交多次后，历史就成了一条链：
A <- B <- C (main)main 是默认分支名（旧版叫 master），它实际上只是一个指向提交 C 的指针。
创建一个新分支，比如叫 dev，Git 做的事情轻量到你无法想象：它只是在 .git/refs/heads/ 目录下写了一个 40 字节的文件，内容是某个提交的哈希值。就这么简单！
A <- B <- C (main, dev)所以分支的本体就是一个可移动的指针，指向某个提交对象。Git 把你每次切换分支后的新提交，都挂在当前分支指针对应的链条上。这就像在科幻电影里打开了平行宇宙，你可以在不同的宇宙中做完全不同的事情，互不干扰，最后还能把宇宙合并回来。
二、创建与切换分支
# 查看所有分支
git branch
# 创建 dev 分支
git branch dev
# 切换到 dev 分支（旧式命令 git checkout dev）
git switch dev新版的 Git 推荐使用 git switch 来切换分支，语义更清晰；git checkout 是一个承载太多功能的命令，容易让人混淆。
也可以一步到位创建并切换：
git switch -c feature-login现在你在 feature-login 分支上。做点事情：
echo "登录模块占位" > login.py
git add login.py
git commit -m "开始开发登录模块"查看历史图：
git log --oneline --graph --all你会看到 feature-login 分支比 main 多出一个提交。
三、合并分支：git merge
功能开发完毕，需要把 feature-login 的成果合并回 main。先切回 main：
git switch -c main然后执行合并：
git merge feature-login如果 main 在分叉之后没有新的提交，Git 会直接将 main 指针"快进"到 feature-login 的位置。这就是 fast-forward 合并 ，相当于把 main 这个标签往前一推，不会产生新的合并提交。
A <- B <- C <- D (main, feature-login)如果你想保留分支的历史轨迹，可以在合并时禁用快进：
git merge --no-ff feature-login这样会生成一个专门的"合并提交"（merge commit），记录下这次合并的发生。在很多团队协作中，--no-ff 是推荐做法，能清晰地看到功能分支的存在。
四、冲突是朋友，不是敌人
当两个分支同时修改了同一个文件的同一行，Git 无法自动决定保留哪个版本，这就产生了冲突（conflict）。
我们来刻意制造一次冲突，并亲手解决它。
4.1 制造冲突
在 main 分支创建一个 config.py：
git switch main
echo "database: mysql" > config.py
git add config.py
git commit -m "设置数据库为 MySQL"然后切到 feature-login 分支，也对 config.py 进行修改：
git switch feature-login
echo "database: postgresql" > config.py
git add config.py
git commit -m "设置数据库为 PostgreSQL"现在 main 里是 mysql，feature-login 里是 postgresql。切回 main 合并：
git switch main
git merge feature-loginGit 会报警：
4.2 查看冲突状态
git status会告诉你 config.py 处于 both modified 状态。
4.3 解决冲突
用编辑器打开 config.py，你会看到：
-
<<<<<<< HEAD和=======之间的内容是你当前所在分支（main）的内容。 -
=======和>>>>>>> feature-login之间的是被合并分支的内容。
你需要手动决定最终留下什么。比如，我们想让配置支持两种数据库，可以改成：
database: mysql, postgresql删除掉冲突标记 <<<<<<<、=======、>>>>>>>，保存文件。
4.4 完成合并提交
git add config.py
git commit -m "解决合并冲突：同时支持 MySQL 和 PostgreSQL"至此，冲突解决完毕。可以在 git log --graph 中看到漂亮的合并历史。
五、变基（Rebase）：另一种合并方式
除了 merge，还有一条路叫 rebase（变基）。它的原理是将一个分支上的提交"挪到"另一个分支的顶端，重演一遍，形成一条笔直的提交历史。
假设你在 feature 分支开发了 D 和 E 两次提交，此时 main 分支又增加了 C1、C2。
D---E feature
/
A---B---C1---C2 main执行 git rebase main（在 feature 分支下）后，会变成：
A---B---C1---C2---D'---E' featurerebase 的优势在于历史更清晰，像一条干净的直线。但它的黄金法则 是：不要对已经推送到公共仓库的提交执行 rebase ，因为 rebase 会改写提交哈希，破坏协作者的本地历史。
本地开发中，如果希望保持整洁，可以多用 rebase；如果在多人协作的分支上，保守使用 merge。
六、分支管理策略与工作流
学习分支操作后，你需要一个指导原则来管理它们。业界最经典的是 Git Flow 与 GitHub Flow。
6.1 Git Flow
适合有计划发布周期的项目。包含长期分支：
-
main：随时可部署到生产环境。 -
develop：集成最新的开发成果。 -
feature/*：从 develop 分出，完成后合并回 develop。 -
release/*：从 develop 分出，用于发布前的测试和微调，完成后合并到 main 和 develop。 -
hotfix/*：从 main 分出，紧急修复生产问题，完成后合并回 main 和 develop。
6.2 GitHub Flow
更适合持续部署的 Web 应用，非常简单：
-
main总是可部署。 -
开发新功能或修复 bug 时，从
main创建描述性的分支，如fix-login-bug。 -
在分支上开发，完成后发起 Pull Request。
-
讨论、审查代码后合并到
main，立即部署。
无论采用哪种工作流，核心思想都是：让分支为你服务，而不是成为负担。
七、操作实践：模拟一次完整的 Git Flow
我们在本地模拟一个微型 Git Flow 流程：
# 初始化项目
mkdir gitflow-demo && cd gitflow-demo
git init
echo "v1.0" > version.txt && git add . && git commit -m "初始提交"
# 创建 develop 分支
git branch develop
git switch develop
# 创建一个 feature
git switch -c feature/greeting
echo "hello" > greeting.txt && git add . && git commit -m "添加问候功能"
# 合并回 develop
git switch develop
git merge --no-ff feature/greeting -m "合并问候功能"
# 准备发布
git switch -c release/1.1 develop
echo "v1.1" > version.txt && git add . && git commit -m "更新版本号至1.1"
# 合并到 main 和 develop
git switch main
git merge --no-ff release/1.1 -m "发布 v1.1"
git switch develop
git merge --no-ff release/1.1 -m "同步发布改动"
# 查看最终历史
git log --oneline --graph --all你会得到一个包含多个合并节点的漂亮历史图。
总结
分支是 Git 中最轻盈、最强大的机制，只是一个指向提交的可移动指针。
git branch 创建分支，git switch 切换，git merge 合并，git rebase 变基。
冲突的产生是因为两个分支修改了同一处内容，手动解决冲突后 git add 并提交即可。
黄金法则：已推送的分支不要 rebase，本地清洁强迫症可以用 rebase，协作多用 merge。
Git Flow 和 GitHub Flow 是两种主流分支策略，根据团队情况选用。
如果这篇文章帮你解决了实操上的困惑，别忘记点击点赞、分享 ，也可以留言告诉我你遇到的其它问题，我会尽快回复。动手练习是掌握编程最快的方法，请务必亲手敲一遍本文的所有示例代码，并截图保存你的成果。你的关注是我坚持原创和细节共享的力量来源，谢谢大家。