第5篇：进阶规范篇 · 团队协作最佳实践
- 前言
- 一、分支命名规范
- [二、提交注释规范（Conventional Commits 业界标准）](#二、提交注释规范（Conventional Commits 业界标准）)
- 三、PR（合并请求）协作规范
- 四、高效协作共识
- 五、新团队快速适配指南
- 系列收尾：Git成长路径总结
前言
本文定义企业级Git协作的标准化规范，所有规则均基于业界通用最佳实践，统一团队协作语言，降低沟通成本，提升代码仓库的可维护性。读完可实现从"会用Git"到"专业、规范地使用Git"的进阶，适配中大型团队的协作要求。
一、分支命名规范
采用「类型/功能标识」的层级命名法，全小写，单词间用连字符（-）分隔，语义清晰，见名知意。
标准格式
<类型>/<功能或缺陷标识>常用分支类型与示例
- 功能开发分支：
feature/user-login-module - 普通缺陷修复：
fix/order-list-null-pointer - 线上紧急修复：
hotfix/payment-timeout-bug - 临时测试验证：
test/api-compatibility-verify（禁止合并入主干） - 版本发布分支：
release/v1.2.0
命名红线
- 禁止使用
test、dev、demo、temp等无明确语义的通用名称 - 禁止使用中文、特殊字符命名分支
- 一个需求对应一条独立分支，禁止复用已删除的旧分支名
二、提交注释规范（Conventional Commits 业界标准）
采用业界通用的约定式提交规范，统一提交信息格式，便于自动生成版本日志、筛选变更记录。
标准格式
<type>: <简短描述>- 描述需简洁具体，说明本次提交的核心改动
- 禁止空白注释、"修复bug""更新代码"等无意义描述
常用类型（type）与定义
| 类型 | 定义 | 示例 |
|---|---|---|
feat |
新增业务功能 | feat: 新增用户手机号登录接口 |
fix |
修复代码缺陷 | fix: 修复订单列表分页参数错误 |
refactor |
代码重构，不改变功能逻辑 | refactor: 抽离用户信息查询公共方法 |
docs |
文档类改动 | docs: 更新接口请求参数说明 |
style |
代码格式调整，不影响业务逻辑 | style: 统一缩进与变量命名规范 |
test |
测试用例相关改动 | test: 补充用户登录模块单元用例 |
chore |
工程化配置、依赖、构建工具改动 | chore: 升级Spring Boot版本至2.7.15 |
三、PR（合并请求）协作规范
PR是团队代码评审的核心载体，规范的PR可大幅降低评审沟通成本，保障代码合入质量。
-
标题清晰明确
直接说明本次PR的核心内容，如「feat: 新增用户手机号登录功能」，避免模糊表述。
-
描述信息完整
补充必要的背景信息，建议包含：需求背景、核心改动点、自测验证情况、关联需求文档或缺陷单链接，帮助评审人快速理解上下文。
-
评审修改规则
评审过程中的修改，优先以追加提交的方式更新，便于评审人查看修改内容；待评审最终通过、合入主干前，可根据团队规范决定是否整理提交记录。
-
合并后及时清理
PR合并通过后，立即删除远程功能分支；本地同步主干代码后，同步删除本地废弃分支，保持仓库整洁。
四、高效协作共识
以下共识是团队顺畅协作的基础，可大幅减少冲突与沟通成本。
-
小粒度频繁提交
完成一个独立功能点就提交一次，不要攒大量改动一次性提交。小粒度提交便于代码评审、问题定位与局部回滚。
-
每日至少同步一次主干
开发过程中定期同步主干最新代码，避免代码偏差越来越大，最后集中爆发大规模冲突。
-
一人一分支一需求
一条功能分支只对应一个需求、仅由一人负责开发；禁止多人共用同一条功能分支，禁止多个需求堆积在同一条分支中，保障代码隔离与独立上线能力。
-
推送前必须本地自测
代码推送远程前，必须本地启动项目验证功能正常、代码可编译通过，禁止将无法运行、存在明显问题的代码推送至公共仓库。
五、新团队快速适配指南
入职新项目、加入新团队时，按以下步骤可快速摸清Git协作规范，避免违规操作：
- 查看远程仓库的常驻分支清单，确认团队采用的工作流模型
- 参考现有分支与提交记录，确认分支命名、提交注释的团队习惯
- 了解PR评审流程、合并策略（Merge/Rebase）与强制推送的权限规则
- 首次提交PR前，可请老同事帮忙确认流程与规范是否符合要求
系列收尾：Git成长路径总结
-
入门阶段：先求稳
熟练掌握Merge安全工作流，严格遵守安全红线，不触碰高风险操作，保障协作不坑队友。
-
进阶阶段：再求精
理解Rebase底层原理，在个人私有分支中使用Rebase整理提交历史，追求整洁的版本记录。
-
专业阶段：守规范
遵循标准化的命名、提交、PR协作规范，从个人操作升级为团队级专业协作。
-
核心原则
所有操作优先考虑「是否会影响团队协作」，公共场景永远以安全稳定为第一优先级，整洁与效率次之。