【11-10】小团队的 Git 协作规范：分支模型、提交信息与代码评审约定

为什么需要规范

小团队最容易犯的错不是没有规范，而是规范太重执行不下去。我们迭代过三版，最终留下的是这套轻量方案。

分支模型

只保留两类长期分支：

• main：随时可发布，受保护，只能通过合并请求进入；

• • feature/*：功能分支，生命周期不超过一周，完成后合并删除。

  • 不设 develop，发布就是给 main 打 tag，简单直接。

• 提交信息

采用 Conventional Commits 简化版：feat: xxx、fix: xxx、docs: xxx 三类前缀。CI 校验提交信息格式，不合格直接拒绝。

代码评审

三条硬规则：

1. 所有代码必须经过至少一人评审才能合并；

2. 2. 评审意见 24 小时内响应，做不到就说明情况；

   3. 3. 评审只关注正确性、可读性与安全，不纠结个人风格，风格问题交给格式化工具。

      4. 最有效的三条经验

   4. • 分支生命周期越短，合并冲突越少；
      • • 提交信息写清楚"为什么"，比写"改了什么"更有价值；
        • • 自动化能解决的事（格式、命名检查）绝不占用人工评审时间。