之前我们介绍了 git 的基础工作流：add → commit → push。但现实开发很快会遇到一个问题：你想尝试一个新功能，但不确定能不能成功，又不想把 main 分支搞乱。比如，想重构一段代码、想试一个新架构、修一个可能越修越坏的 bug。 这时候，如果所有修改都直接提交到 main，项目很容易进入混乱状态。Git 分支，就是为了解决这个问题而存在的
一、分支是什么
分支可以理解为一条独立的提交时间线。你从 main 上某个节点"分叉"出去，在新分支上自由提交、修改，main 完全不受影响。做好了再合并回去，做坏了直接删掉。
注意，分支不是"复制一份代码"，它只是一个指针，指向某个 commit 节点。创建分支几乎没有开销，这也是 Git 能支持大量并行开发的原因。
二、分支基础操作
2.1 创建并切换分支
bash
git checkout -b feature/login 其中，-b 表示新建分支，feature/login 是分支名。
这条命令等价于：
bash
git branch feature/login # 创建
git checkout feature/login # 切换过去 现代 git 更推荐使用 git switch：
bash
git switch -c feature/login # -c 等同于 -b，create 的意思 分支名的约定 ：feature/ 前缀表示新功能，fix/ 表示修 bug，release/ 表示发布准备，hotfix/ 紧急修复。Git 不强制，但统一规范会带来两个好处： 分支列表一眼可读 ，CI/CD 自动化更容易配置。
2.2 查看当前在哪个分支
bash
git branch 输出里带 * 的就是当前分支：
* feature/login
main 本质上，HEAD 指针正在指向这个分支。
2.3 在新分支上正常开放
切到新分支后，工作流和之前完全一样：改代码 → git add → git commit。唯一不同的是，commit 被记录在 feature/login 这条时间线 上，不会影响 main。
2.4 切回 main
bash
git switch main 切回去之后，你会发现工作目录恢复成了 main 的状态，在 feature 分支上做的改动"消失了"。它们没有被删除，只是 git 切换了当前指针，feature 分支的内容还在，切回去就能看到。
其实，这里Git 并不是在"改文件"。Git 在做的是：切换整个项目的历史快照。
2.5 合并分支
feature 做好了，合并回 main：
bash
git switch main
git merge feature/login git 会把 feature/login 上的 commit 合并到 main。如果两条分支没有修改同一个地方，合并是自动完成的。
合并完之后，feature 分支就可以删掉了。因为历史已经进入 main，不再需要它。
bash
git branch -d feature/login三、冲突：两个人改了同一个地方
合并时最常见的麻烦是冲突（conflict），你和别人都修改了同一个文件的同一段代码，git 不知道该保留哪个，就会暂停合并，让你手动决定。
3.1 冲突内容
冲突文件会变成这样：
bash
<<<<<<< HEAD
def greet(name):
return f"Hello, {name}!"
=======
def greet(name):
return f"Hi, {name}!"
>>>>>>> feature/login 其中，<<<<<<< HEAD 到 ======= 是你当前分支的版本，而======= 到 >>>>>>> 是要合并进来的版本
3.2 解决方法
直接编辑文件，删掉你不想要的那段和所有 <<<<<<<、=======、>>>>>>> 标记，留下最终想要的代码，然后告诉git你已经解决：
bash
git add 冲突文件名
git commit 冲突解决完毕。
冲突不是 git 的 bug，是正常现象。解决原则很简单：两个版本都看一眼，留你想要的，删掉标记符号，重新提交。冲突是 Git 的安全机制，而不是失败。
四、推送分支到 GitHub
本地分支推到远程：
bash
git push origin feature/login 推上去之后，可以在 GitHub 上开一个 Pull Request（PR），这是"我想把这个分支合并到 main"的申请，团队成员可以在上面 review 代码，CI 也会在这里跑。
PR 通过后，点 GitHub 上的 Merge 按钮，就完成了合并。合并完可以在 GitHub 上直接删掉远程分支，本地也同步清理：
bash
git branch -d feature/login # 删本地分支
git remote prune origin # 清理本地对已删除远程分支的引用五、典型的分支工作流
独立项目和团队协作的分支策略不一样。
5.1 独立项目（简单策略）
main ← 只放稳定、可用的代码
feature/* ← 每个新功能一个分支，做好合并回 main
fix/* ← 每个 bug 修复一个分支5.2 团队协作（常见策略）
main ← 对应生产环境，只接受 PR 合并，不直接 push
dev ← 日常开发的集成分支，功能分支合并到这里先验证
feature/* ← 从 dev 分叉，完成后合并回 dev 不需要在第一个项目就用最复杂的策略，从"main + feature 分支"开始，感受到不够用再升级。
六、总结
记住这几个核心认知，你就真正理解分支了：
-
分支是一条提交历史线
-
分支不是复制代码，而是指针
-
切换分支 = 切换项目快照
-
merge 是历史的合流
-
冲突是 Git 请求人工决策
git分支可以让我们安全试错，而软件开发本质上就是持续试错。