为什么需要分支模型
在团队协作中，分支模型决定了代码如何集成、发布和修复。一个好的模型能减少冲突、提高交付效率；一个糟糕的模型则会让合并变成噩梦。本文从零开始，帮你理解常见分支模型的核心思想，并给出选择建议。
常见分支类型
主干分支（main/master）
主干分支代表当前稳定的、可发布的代码。所有开发最终都要合并回主干。通常主干分支受保护，不允许直接推送，必须通过合并请求（Pull Request）或合并请求（Merge Request）进行代码审查。
特性分支（feature branch）
特性分支用于开发新功能或修复缺陷。命名建议使用 feature/xxx 或 fix/xxx 前缀。特性分支的生命周期应尽量短，避免长期偏离主干导致合并困难。
发布分支（release branch）
发布分支用于准备新版本发布。在发布分支上只做 bug 修复和版本号更新，不再添加新功能。发布完成后，需要将发布分支合并回主干，并打上标签（tag）。
热修复分支（hotfix branch）
热修复分支用于紧急修复生产环境的问题。它通常从主干或最近的发布标签创建，修复后同时合并回主干和发布分支。
两种主流分支模型
Git Flow
Git Flow 定义了严格的分支角色：main、develop、feature、release、hotfix。
- 优点：职责清晰，适合有明确发布周期的项目。
- 缺点：分支多，流程重，不适合持续交付。
GitHub Flow
GitHub Flow 更简单：只有一个长期分支 main，所有改动都通过特性分支和合并请求进行。
- 优点：简单灵活，适合持续部署。
- 缺点：对自动化测试和代码审查要求高。
如何选择
- 如果团队需要维护多个版本（如软件产品），Git Flow 更合适。
- 如果团队采用持续交付（如 Web 服务），GitHub Flow 更高效。
- 也可以折中：使用主干分支 + 特性分支 + 发布标签，不设 develop 分支。
合并策略详解
快进合并（Fast-forward）
当特性分支基于主干的最新提交时，合并可以直接移动指针，不产生合并提交。历史呈线性，但会丢失分支信息。
git checkout main
git merge --ff-only feature/xxx
三方合并（Merge commit）
当分支有分叉时，Git 会创建一个合并提交。保留完整历史，但历史图会变得复杂。
git checkout main
git merge --no-ff feature/xxx
变基（Rebase）
将特性分支的提交“搬移”到主干最新提交之后，形成线性历史。
git checkout feature/xxx
git rebase main
注意：不要对已经推送到远程的公共分支进行变基，否则会重写历史，影响他人。
压缩合并（Squash merge）
将特性分支的所有提交压缩成一个提交合并到主干。历史干净，但丢失了开发过程中的细节。
git checkout main
git merge --squash feature/xxx
git commit
实践建议
- 保持分支短小：特性分支存活时间最好不超过几天。
- 频繁同步主干：定期将主干变更合并或变基到特性分支，减少冲突。
- 统一合并策略：团队应约定一种主要策略（如 squash merge），避免混乱。
- 保护主干：启用分支保护，要求代码审查和 CI 通过。
- 自动化测试：无论选择哪种模型，完善的测试是安全合并的前提。
总结
没有“最好”的分支模型，只有最适合团队和项目的模型。理解主干、特性分支和合并策略的优缺点，结合发布节奏和团队规模，才能做出明智选择。从简单开始，随着需求演进再调整，是更务实的做法。