分支协作模型

讲解

单枪匹马时分支随便用，团队协作就需要约定「什么代码进哪个分支、怎么进」——这就是分支模型。最流行的是 GitHub Flow，简单到三条规则：main 永远是可发布的状态；做任何事都从 main 岔一个短命的功能分支；完成后发起 Pull Request（PR），经评审和自动化测试后合并回 main，随即删除功能分支。它适合持续部署的 Web 项目，本系列教程的所有站点都用这种模式工作。

历史更久的是 Git Flow：main 存正式发布，develop 存开发主线，功能从 develop 岔出再合回，发布时拉 release 分支稳定化，线上 bug 拉 hotfix 分支修复后同时合回 main 和 develop。结构严谨，适合有明确版本周期的软件（客户端、库），但分支多、流程重，小团队往往觉得繁琐。还有一种 Trunk-Based Development（主干开发）：所有人直接在 main（或极短命的分支）上高频提交，靠功能开关（feature flag）隐藏未完成的功能，配合强大的 CI 保证主干常绿——Google 等大厂的大规模协作走这条路。

怎么选？小团队做 Web 产品，GitHub Flow 足够；要同时维护多个已发布版本（比如 1.x 和 2.x 都要打补丁），Git Flow 或它的简化版更合适；追求极致的集成频率且有成熟 CI，才考虑主干开发。无论选哪种，共同的底线是：main 永远可用、功能分支短命、合并前评审 + 自动化测试、合并后删分支。模型是手段不是目的，流程服务于「减少集成痛苦」。

示例

走一遍 GitHub Flow 的完整循环（远程用本地仓库模拟）：

git remote add origin ../origin.git
git push -q -u origin main

git switch -c feature/search
echo "搜索功能" > search.txt
git add search.txt
git commit -qm "feat: 搜索功能"
git push -q -u origin feature/search

git switch main
git merge --no-ff feature/search -m "merge: 合入搜索功能"
git push -q origin main
git branch -d feature/search
git log --oneline --graph -3

真实团队里，git push feature/search 之后会在 GitHub 上发起 Pull Request，同事评审、CI 跑测试，都通过后点合并——对应示例里的 merge --no-ff 那一步，--no-ff 保留合并提交，让「这个功能是作为一个整体进来的」在历史中清晰可见。

常见坑

• 直接在 main 上提交：绕过了评审和 CI 这两道保险，main 随时可能坏掉。团队里应该把 main 设为受保护分支，只允许通过 PR 合并。
• 功能分支活太久：一个分支开发两周，合并时冲突成片。把大功能拆成几个可以独立合并的小 PR，一两天内合回主线。
• 合并后不删分支：远程上堆着几百个已合并的分支，找活跃分支像翻垃圾堆。合并即删除，需要历史时提交永远在。
• 生搬硬套 Git Flow：三五个人的 Web 团队维护 develop/release/hotfix 全家桶，流程成本远超收益。先选最简单的模型，痛了再升级。

小结

GitHub Flow（main + 短命功能分支 + PR）适合大多数 Web 团队；Git Flow 应对多版本维护；主干开发依赖强 CI。共同底线：main 常绿、分支短命、合并前评审。最后一章总结全教程的最佳实践。