4、Git分支管理：分支概念、创建与切换分支、合并分支、解决冲突、分支策略
分支这东西，说白了就是让你在同一个仓库里，开辟出多个平行宇宙。每个宇宙里你可以随便改代码，互不干扰。我刚开始用Git时，觉得分支可有可无，直到有一次我在主分支上直接改bug，改到一半又被拉去写新功能……嗯，那场面，简直是一团乱麻。从那以后，我再也不敢裸奔在主分支上了。
分支概念：为什么你需要平行宇宙？
Git的分支，本质上就是一个指向某个提交对象的可变指针。每次你提交，这个指针就自动向前移动。默认情况下，我们都在 master 或 main 分支上工作。
你想想看，如果没有分支，所有人都在一条线上改代码，那会是什么场景？A改了一行，B也改了一行，两个人互相覆盖，最后谁都不知道代码到底长什么样。分支就是用来解决这个问题的。
核心理解：分支不是复制整个仓库，而是创建一个新的指针。创建分支的成本极低，几乎为零。所以，大胆地创建分支吧！
我个人习惯，每开始一个新功能或修复一个bug，第一件事就是创建一个新分支。这样主分支永远保持干净、可部署的状态。
创建与切换分支：动手试试
创建分支非常简单，就一个命令：
# 创建一个新分支，但不会自动切换过去
git branch feature-login
# 创建并立即切换到新分支（我常用这个）
git checkout -b feature-login
# 或者用新版命令（推荐）
git switch -c feature-login切换分支也很直接：
# 切换到已有分支
git checkout feature-login
# 或者
git switch feature-login我的小技巧：切换分支前，一定要确保当前工作区是干净的。用 git status 看一眼，如果有未提交的修改，要么提交，要么暂存起来。我曾经因为忘了这步，把改到一半的代码带到了另一个分支，结果两个分支都乱了套。
你可能会问：checkout 和 switch 有什么区别？其实 switch 是Git 2.23之后引入的新命令，专门用来切换分支，语义更清晰。而 checkout 身兼数职，既能切分支又能恢复文件，容易让人混淆。我个人现在都用 switch 了。
合并分支：把平行宇宙连起来
功能开发完了，就要把分支合并回主分支。合并有两种主要方式：
| 合并方式 | 命令 | 特点 |
|---|---|---|
| 普通合并 | git merge feature |
保留完整历史，会生成一个合并提交 |
| 快进合并 | git merge --ff-only feature |
线性历史，不会产生合并提交 |
| 变基合并 | git rebase feature |
历史更干净，但会改写提交 |
实际操作中，我一般这样做：
# 先切回主分支
git switch main
# 拉取最新代码
git pull origin main
# 合并功能分支
git merge feature-login注意：合并前一定要确保主分支是最新的。我见过有人合并了一个过时的主分支，结果把别人已经合并的代码又给覆盖了。那场面……嗯，不太好看。
解决冲突：不可避免的"撞车"
冲突，说白了就是两个人改了同一行代码，Git不知道该听谁的。别慌，这很正常。我刚开始遇到冲突时，吓得差点把仓库删了重来。其实解决起来没那么可怕。
当合并发生冲突时，Git会在文件中标记出冲突区域：
<<<<<<< HEAD
这是主分支的代码
=======
这是功能分支的代码
>>>>>>> feature-login解决步骤：
- 打开冲突文件，找到
<<<<<<<标记 - 手动编辑，保留你想要的内容，删除标记符号
- 保存文件
- 用
git add标记为已解决 - 用
git commit完成合并
避坑指南：我曾经在解决冲突时，不小心把别人的代码全删了。后来养成了一个习惯：解决冲突前，先用 git diff 看清楚两边改了啥，再动手。另外，如果冲突文件太多，可以用 git mergetool 启动可视化工具，直观很多。
分支策略：团队协作的"交通规则"
分支策略，就是团队约定好怎么用分支。没有规矩，不成方圆。我见过最混乱的团队，所有人都在主分支上直接提交，结果上线前谁都不敢打包票代码是好的。
这里介绍几种常见的分支策略：
| 策略名称 | 适用场景 | 核心思想 |
|---|---|---|
| Git Flow | 大型项目、有固定发布周期 | main、develop、feature、release、hotfix 五类分支 |
| GitHub Flow | 持续部署、小团队 | 只有main分支，功能分支通过PR合并 |
| GitLab Flow | 需要环境分支 | 在GitHub Flow基础上增加环境分支 |
我个人比较推荐小团队用GitHub Flow，简单直接。大项目用Git Flow，虽然复杂点，但结构清晰。
我的经验：不管用哪种策略，有几点是通用的：
- 主分支永远保持可部署状态
- 功能分支从主分支拉出，完成后合并回去
- 合并前做代码审查（Code Review）
- 及时删除已经合并的分支，保持仓库整洁
说到删除分支，命令也很简单：
# 删除本地分支
git branch -d feature-login
# 删除远程分支
git push origin --delete feature-login注意：删除分支前，确认这个分支的代码已经合并到主分支了。用 git branch --merged 可以查看哪些分支已经合并。别问我怎么知道的……我曾经手滑删了一个还没合并的分支，那感觉，就像考试交卷后发现最后一道题做错了。
好了，分支管理这块就聊到这儿。记住一句话：分支是你的朋友，不是敌人。多用分支，你的代码生活会轻松很多。