Git 分支管理与团队协作规范实践

Git 用得久了会发现：规范带来的不是束缚，而是"不用动脑就知道怎么做"的确定性。本文分享一套轻量的分支与提交规范。

1. 选择合适的分支模型

对于中小型项目，主干开发 + 短生命周期分支通常比复杂的 Git Flow 更高效：

• main：始终可发布的主干，禁止直接提交。
• feat/xxx：功能分支，从 main 切出，合并后删除。
• fix/xxx：缺陷修复分支，优先小步合入。

团队规模大、需要定期发版时，可再引入 release/x.y.z 与 hotfix/xxx 分支。

2. Commit 规范：让历史可读

建议提交信息采用 类型(范围): 描述 的格式，例如：

feat(auth): 增加手机号验证码登录
fix(style): 修复移动端导航栏溢出
docs(readme): 补充本地开发指引
refactor(api): 统一错误响应结构

常用类型：feat 新功能、fix 修复、docs 文档、style 格式、refactor 重构、test 测试、chore 杂项。

3. 合并策略：优先 Rebase 保持线性

拉取远端更新时，建议用 rebase 保持本地提交线性，避免无意义的 merge commit：

# 同步主干并保持线性历史
git fetch origin
git rebase origin/main

# 推送前先检查将要推送的内容
git log --oneline origin/main..HEAD

多人并行开发的特性分支合回主干时，用 --no-ff 保留一条清晰的合并记录即可。

4. 代码评审的细节

• PR 越小越好，控制在「能一次讲清」的粒度。
• 评审先看行为是否与描述一致，再看边界与异常分支。
• 用 suggestion 直接给出可落地的修改方案，减少来回沟通。

小结

规范的意义在于把"约定"变成"默认"。从 Commit 格式和分支命名开始，成本最低、收益最直接，值得每个团队先做起来。