为了保持代码仓库的整洁和一致性，以及提高团队协作效率，我们需要规范Git的使用方式，包括分支（branch）、提交（commit）、标签（tag）的管理。
分支（Branch）
主分支（master）
- 项目的主分支，有且仅有一个。主要用于存放和记录整个项目已完成的功能代码。
- 除项目负责人外，其他开发人员不得直接向 master 分支合并内容。
- 通常与线上的生产环境（prod）相对应。
开发分支（develop）
- 主开发分支，有且仅有一个。用于存放和记录所有确定性的功能（上线和未上线）。
- 各功能开发完成后，经过测试（qa）和验证（release/pre）的功能可以合并到该分支。
- 开发新功能、修复 BUG 时从主开发分支拉取代码到各新分支进行开发
- 功能分支（feature）：用于开发新功能，命名规范通常为 feature/{feature_name}
- 紧急 BUG 修复分支（hotfix）：用于修复紧急的线上 BUG，命名规范通常为 hotfix/{bug_name}
- 非紧急 BUG 修复分支（bugfix）：用于修复非紧急的 BUG，命名规范通常为 bugfix/{bug_name}
测试分支（qa）
- 测试分支，有且仅有一个。由主要开发人员通过合并请求实现测试部署，交予测试人员进行质量校验。
- 禁止直接对该分支提交内容，测试分支应该由开发分支提交合并请求而来。
- 通常与质量测试环境（qa）相对应。
验证分支（release/pre）
- 预发布分支，有且仅有一个。在发布正式版本之前，需要有一个预发布的版本进行验证。
- 各功能开发完成后，经过测试（qa）的功能可以合并到该分支。
- 通常与预生产环境（pre）相对应。
提交（commit）
提交原则
- 每次提交应只包含一个功能或修复一个 BUG，避免混合多个不相关的改动。
- 提交信息应该清晰明了，能够准确反映代码改动的内容和目的。
提交格式
# Header头
():
# Body
()
# Footer
()
() type
类型
属性 | 描述 |
feat | 增加新功能 |
fix | 修复 bug |
docs | 只改动文档相关的内容 |
style | 不影响代码含义的格式修改，比如去掉空格、改变缩进、增删分号 |
refactor | 重构（既不是新增功能，也不是修改 BUG 的改动） |
build | 构建工具或外部依赖的改动 |
revert | 回滚版本 |
test | 添加测试或修改现有测试 |
perf | 性能提升 |
chore | 不修改 src 或 test 的其余改动，例如构建过程或辅助工具的变动 |
ci | 与 CI（持续集成服务）有关的改动 |
scope
影响范围，一般为修改的模块或者功能
subject
简短描述，5~10 个字简单描述做的任务
body
详细描述，对于功能详细的描述，解释为什么加入这段代码，为什么调整优化等
breaking changes
当前版本与之前版本不兼容，如迭代升级对之前版本不能做到兼容，就需要在 breaking changes 后面描述变动理由和迁移方法之类，不常用
closed issue
当前提交针对某个 issue 问题或是 bug 编号等
示例：
fix(登录模块)：修改登录方式
将账号密码登录调整为手机号验证码快捷登录
breaking changes：登录逻辑调整，不兼容老版本
closed #1026可使用 IDEA 的 Git Commit Message Helper 插件统一标准规范
标签（tag）
版本标签
- 用于标记项目的稳定版本，方便回溯和发布。
- 命名规则：{分支名称}_v{版本号}_{日期}。其中，版本号：{主版本号}.{次版本号}.{修订版本号}；日期格式：yyyyMMdd。
其他标签
- 根据需要创建其他类型的标签，如里程碑标签、特殊功能标签等。
- 命名应清晰明了，避免歧义。