烟台的小开发团队，Git用得千奇百怪：master上直接改代码、提交信息全是”修改””修复”、两个人一改同一个文件就抓瞎。Git不是装上就会用，分支策略和提交规范是团队效率的地基，这篇聊聊我们给小团队定的实操规范。
小团队的分支模型
大厂的重型分支流程对小团队是负担，我们的建议很简单：master保稳定随时可发布，开发在功能分支上做，完成后合回。规则两条：master不许直接提交，功能分支存活不超过一周——分支活得越久，合并冲突越疼。紧急修复走hotfix分支，修完即合即删，不留僵尸分支。
提交信息的价值
”修改”这种提交信息，三个月后连自己都不知道改了什么。规范很简单：一句话说清做什么，如”修复：订单金额计算四舍五入错误”。提交要小而完整：一个提交做一件事，回滚和排查都精准——大杂烩提交是排查事故时最大的敌人。提交前diff一遍自己的改动，这是最便宜的代码审查。
协作的保护性约定
合并请求哪怕只有一个人看，也比直接推强——过一遍就拦得住一半的低级错误；敏感配置不进仓库，密码密钥放配置中心或环境变量。信服无限网的交付流程里，代码审查是质量门禁的一环，Git规范是审查能跑起来的前提——规范不是约束人，是保护团队。烟台信服无限给本地团队做开发流程与工具链咨询，按服务项评估，一案一价。
Git规范的常见疑问
要上复杂工作流吗？
不用，小团队两三条规则执行到位，胜过十页流程文档。
历史提交能改吗？
未推送的可改，已共享的历史别重写，团队约定好即可。
冲突频繁怎么办？
缩短分支存活时间、拆小功能粒度、勤拉主分支更新。
总结
烟台小团队的Git规范：master保护加短命功能分支、提交信息说人话加小而完整、合并请求加敏感信息隔离，三条执行到位效率立现。工具纪律是团队的地基，地基稳了再谈架构。规范不是约束，是保护。