分支管理：分支概念、创建与切换、合并与冲突解决
说到版本控制，分支绝对是核心中的核心。我记得刚入行那会儿，团队还在用 SVN，大家共用一条主干，谁都不敢轻易提交代码。每次合并都像在拆弹，特别痛苦。后来切到 Git，学会了分支管理，才真正体会到什么叫「随心所欲不逾矩」。说白了，分支就是给你一个平行宇宙，你在里面随便改，改完了再合并回来——前提是你得知道怎么用。
分支是什么？为什么需要它？
分支，本质上是 commit 的一个可移动指针。当你创建一个新分支，Git 只是新建了一个指针，指向当前所在的 commit。这个操作几乎是瞬时的，不涉及文件拷贝。你想想看，如果每次分支都复制全部文件，那该多慢。
在实际项目中，分支解决了几个核心痛点：
- 隔离开发：每个人在各自分支上干活，互不干扰。
- 实验性尝试：想试个新方案？建个分支，成了就合并，废了就扔掉。
- 并发协作：多人同时开发不同特性，最后汇合。
- 发布管理：稳定版本、修复分支、功能分支，各司其职。
核心思想：分支是轻量级的，成本极低。不要怕建分支，多建分支反而安全。我见过一些团队死守 master，结果一改代码整个工程崩掉，那就是对分支没信心。
创建与切换：基本操作
Git 分支操作非常直接。常用的命令就这么几条：
# 查看本地分支（* 表示当前分支）
git branch
# 创建新分支（不切换）
git branch feature-login
# 切换分支
git checkout feature-login
# 创建并立即切换（快捷方式）
git checkout -b feature-login
# 在新版 Git 中，推荐用 switch 代替 checkout
git switch -c feature-login我个人习惯用 git switch -c，语义更清晰。偶尔也会用 checkout -b，因为手指记忆改不过来。嗯，这个小习惯其实无所谓，团队统一就好。
小技巧：切换分支前确保工作区干净。如果还有未提交的修改，可以用 git stash 暂存起来，切回来再 git stash pop。我在一个紧急修复场景里用过这招，当时改了一半的功能，突然线上出问题，先 stash 掉，切回 master 修 bug，修完再切回来继续。
分支模型：一个简单的工程实践
虽然 Git 建议你用任意方式分支，但在项目里最好形成套路。下面这个表格展示了我在 Pipeline 构建项目中常用的分支设计：
| 分支名 | 用途 | 生命周期 | 从哪创建 |
|---|---|---|---|
master / main |
发布分支，只包含可发布的版本 | 永久 | — |
develop |
日常开发集成分支 | 永久 | 从 master 初次创建 |
feature/* |
新功能开发 | 短期（开发完成即合并到 develop） | 从 develop 创建 |
release/* |
发布前测试与修复 | 短期（发布后合并回 master 和 develop） | 从 develop 创建 |
hotfix/* |
线上紧急修复 | 短期（修复后合并回 master 和 develop） | 从 master 创建 |
曾经踩过的坑：有一次团队把 feature 分支直接合并到 master，没有经过 develop 集成的步骤。结果两个 feature 之间互相冲突，线上出了严重 bug，回滚花了一个小时。从此我们立下规矩：所有 feature 必须先合并到 develop，集成测试通过后，再用 release 分支做发布前验证。
合并：两种方式与差异
合并操作有两种主要方式：普通 merge 和 rebase。目的都是把两个分支的历史整合到一起，但结果不同。
普通 merge 会生成一个合并提交（merge commit），保留两条分支的完整历史。适合公共分支（如 develop、master）的合并，因为你能看到「哪两次开发被合并了」。
git checkout develop
git merge feature-loginRebase 则把当前分支的提交「变基」到目标分支前面，历史是一条直线。适合个人分支或还没共享的分支，历史更整洁。
git checkout feature-login
git rebase develop我个人习惯：在 feature 分支开发时，每天 rebase 一下 develop 保持最新，减少后期合并冲突。但 feature 合并回 develop 时，用普通 merge，保留合并点。
| 特性 | Merge | Rebase |
|---|---|---|
| 历史结构 | 保留分支拓扑，有 merge commit | 线性历史，无 merge commit |
| 冲突处理 | 一次解决，产生 merge commit | 每个 commit 依次解决，可能多次 |
| 适用场景 | 公共分支、发布分支 | 个人分支、尚未共享的提交 |
| 对他人影响 | 无 | 如果已推送相同分支给他人，rebase 会改写历史，需谨慎 |
建议：团队内统一约定。我在 Pipeline 项目中，要求 feature 分支必须 rebase 到最新 develop 后再提 MR（Merge Request），避免 MR 里出现一堆冲突。但 release 和 hotfix 分支一律用 merge，保留明确的发布节点。
冲突解决策略：别怕，有套路
冲突是分支管理的常态。说白了就是两个人改到了同一行代码，Git 不知道该听谁的。我刚开始遇到冲突时手忙脚乱，后来总结出一套流程，基本上不会出问题。
第一步：了解冲突标记
当你执行 git merge 或 git rebase 时，Git 会告诉你哪些文件冲突。打开冲突文件，你会看到类似下面的内容：
<<<<<<< HEAD
这里是你当前分支的代码
=======
这里是你要合并进来的代码
>>>>>>> feature-login你需要手动编辑，删掉冲突标记，保留你想要的内容。
第二步：使用可视化工具
我不建议手动编辑大文件。用 git mergetool 可以调出图形界面对比工具。我常用 vimdiff 或 meld，但团队环境如果不支持，用 VS Code 自带的冲突解决也很方便。
# 配置你的合并工具（以 meld 为例）
git config merge.tool meld
# 然后遇到冲突时运行
git mergetool第三步：策略性合并
有些冲突可以通过策略避免或缩小范围：
- 频繁同步：每天至少 rebase 一次 develop，冲突会小很多。
- 模块化代码：避免两个人同时改同一个文件的同一区域。Pipeline 构建中，我通常把配置文件、构建脚本划分好，每个人负责自己的模块。
- 先沟通：如果发现冲突很大，先和同事确认一下意向，再合并。
曾经踩过的坑：有一次合并冲突，我手动编辑后忘了删掉冲突标记，直接提交了。结果编译通不过，排查了半天才找到原因。从那以后我每次解决冲突后都会 grep 一下文件，确保没有 <<< >>> === 残留。
整体流程：一张图看懂
下面是分支管理中从创建到合并的核心流程，用一个 SVG 展示：
这个流程是我在多个 Pipeline 项目中验证过的。你看，从 develop 创建 feature，开发中定期 rebase 保持同步，完成后提 MR 合并回 develop，有冲突就解决，最后用 release 分支做上线前验证。整个流程清晰可控。
避坑指南
我曾经踩过的另一个坑：以为 rebase 是万能的，结果把一个已经推送到远程的 feature 分支 rebase 了，然后 force push 覆盖了同事的提交。那个同事只能重新拉取。从此我定了一个铁律：已经推送到远程且他人已基于此分支的分支，禁止 rebase。如果实在需要整理历史，先和团队沟通好，大家一起同意再操作。
另外，合并时记得先拉取最新的远程分支。我经常遇到这种情况：本地以为自己是最新的，结果 push 时发现冲突，又要重新解决。现在每次合并前我都会：
git checkout develop
git pull --rebase # 先拉取最新
git checkout feature-login
git rebase develop # 在 feature 上 rebase
# 然后解决可能出现的冲突
# 最后推送到远程并提 MR小建议：写一个好的 commit message 对合并极其重要。我看到过这样的消息："fix bug""update""test"。你想想看，几周后回来，你知道哪个 commit 对应哪个功能？我习惯用「类型(范围): 简短说明」格式，比如 feat(login): add OAuth2 support。这样在合并时，一眼就能看出每个提交的目的。
好了，分支管理的基本理念和操作就是这些。记住，分支不是洪水猛兽，而是你的盟友。多建分支、勤同步、及时合并，代码质量和协作效率都会提升一大截。