三人到十几人的团队，不需要照搬大厂全部流程。目标很简单：主分支始终可发布，改动可回顾，冲突可预期。

推荐的主干模式

  • main（或 master）：受保护，只接受合并请求。
  • feature/xxx：从最新 main 拉出，做完开 PR。
  • 紧急修复：hotfix/xxx，修完尽快合回 main。

长期存在的 develop 分支对小团队往往是负担；除非发布节奏真的很复杂，否则「主干 + 短命功能分支」更轻。

提交信息写什么

好的提交说明回答「为什么」，而不是复述 diff。可用约定：

fix: 避免空状态重复请求列表接口

用户在弱网下连续点击刷新时，会触发多次相同请求，
导致列表闪烁。增加进行中标记后只保留一次飞行中请求。

前缀可选：feat / fix / docs / refactor / chore。团队统一即可，不必过度仪式化。

合并前的最低检查

  1. 基于最新 main 变基或合并，减少集成冲突。
  2. 自测关键路径；有自动化测试就跑一遍。
  3. PR 描述写清：改了什么、如何验证、有无风险。
  4. 至少一人 review；小改动也可「轻量看一眼」。

冲突怎么少一点

  • 分支寿命尽量短（一两天内合入）。
  • 少同时改同一巨型文件；必要时先拆文件再并行。
  • 格式化与 lint 统一配置，避免「纯空格冲突」。

不建议的习惯

  • 直接 push 到 main。
  • 一个 PR 塞多个无关需求。
  • 强制推送共享分支（除非团队明确约定且知情）。
  • 提交信息写「update」「fix bug」却不说明对象。

小结

小团队 Git 协作的核心不是工具花哨，而是：短分支、可读提交、受保护的主干、可验证的 PR。把这四件事做稳，协作成本会明显下降。