一个适合小团队的分支管理模型：从 feature 到 release

很多小团队一上来就照搬 Git Flow，结果发现分支多到连自己都记不住：develop、release、hotfix、feature，每个人每天在各种分支间切换，merge 冲突不断。其实对小团队来说，越简单越好。

主干开发 + 短生命周期 feature 分支

核心原则：main 分支永远保持可发布状态。所有新功能从 main 拉出 feature 分支，完成后合并回 main。

git checkout -b feature/user-login
# ... 开发、提交 ...
git push origin feature/user-login
# 发起 PR，评审后合并回 main

什么时候才需要 release 分支

只有当团队需要同时维护「线上稳定版」和「下一版开发」时才引入：

• main：持续集成的开发主线
• release/x.y：准备发布的版本，只做 bug 修复
• hotfix/x.y.z：紧急线上修复，合并到 main 和 release

提交信息规范

与其纠结是否用 Conventional Commits，不如先做到「一条提交做一件事，说清楚为什么」。将来 git log 或 git bisect 排查时，会感谢现在规范写提交信息的自己。

冲突怎么少一点

• feature 分支存活时间越短越好，尽量一天内合并
• 频繁 rebase 主干，而不是憋到最后一次性 merge
• 大功能拆成可独立合并的小提交

小结

分支模型没有银弹，关键是匹配团队规模和发布节奏。小团队求快、求稳，主干开发 + 短命 feature 分支往往就是最优解。