见过太多团队Git用得乱七八糟——feature分支活了两个月、merge conflict天天有、线上出bug不知道哪个版本引入的。花一天规范好分支管理，后面省的时间按月算。
我现在的团队用的是一套简化版的分支策略。三个长期分支：main（生产环境）、staging（预发布）、develop（开发主线）。所有的feature从develop切出，完成后merge回develop。develop测试通过后合并到staging，staging压测通过后合并到main打tag发布。
关键规则只有五条。第一条：feature分支的生命周期不超过三天。超过三天说明任务拆得不够细，分支越长冲突风险越大。第二条：每天下班前把develop合并到自己的feature分支。避免最后合并时面对两千行的冲突。第三条：commit message用约定式提交——feat/fix/docs/chore加冒号加简短描述。配合standard-version工具可以自动生成CHANGELOG和版本号。第四条：永远不直接在main和staging上改代码，Hotfix也从main切，修完同时合并到main和develop。第五条：合并用rebase而不是merge，保持提交历史是一条直线。当然rebase有风险，核心原则是"只rebase你还没推送到远程的提交"。
工具推荐两个。GitKraken或者lazygit做可视化操作，比命令行直观，尤其是解决冲突的时候。commitlint + husky做提交前检查，防止"fix bug"这种无意义的提交信息混进去。
这套方法跑了一年多，线上事故回滚从来不超过五分钟——因为每次发布只有一个tag之间的变更，git log v1.2.3..v1.2.4一眼看完。
还木有评论哦，快来抢沙发吧~