开发规范-GIT提交规范

代码提交规范篇

1. 【推荐】代码提交应该短小而频繁，尽量避免单次提交大量代码。
   说明：约束单次提交的范围有利于写出更加针对性的说明，也对代码审核更加友好。
   反例：单次提交超过200+行的代码或20+的文件；只在休息的时候（午休、下班）提交代码；很难一句话说清楚这次提交的内容
2. 【强制】代码提交说明应该描述本次提交的具体内容，并带上适当的前缀
   • feat：新功能的说明，例子：登陆页面；注册页面
   • fix：修补bug的说明
   • docs：增加文档、注释
   • style： 调整代码格式（不影响任何代码逻辑的变动）
   • refactor：代码重构（既不是新增功能，也不是修改bug的代码变动）
   • test：增加测试
   • chore：构建过程或辅助工具的变动
   • 反例：无意义的说明比如“优化”、“bug fix”、“test”
3. 【推荐】代码提交说明字数控制在20字以内
4. 【推荐】代码提交说明无须以句号结尾

为什么需要规范化代码提交？

1. 提供更多的历史信息，方便快速浏览
   git log HEAD --pretty=format:%s
2. 可以过滤某些commit（比如功能性提交），便于快速查找信息
   git log HEAD --pretty=format:%s | grep feat
3. 可以直接从commit生成某个release的变更日志
   参考conventional-changelog工具
4. 可以利用工具自动生成符合规范的commit message前缀
   参考commitizen工具
5. 对代码审核更加友好，通常直接review一个大的版本非常困难，而筛选出所有功能性提交（feat前缀）单独review则简单很多

分支管理规范

1. 普通仓库
   如果一个仓库的每个版本包含的功能列表是相对稳定的，一旦版本确定就不会随意增删功能，那么这就是一个普通类型的仓库，这类仓库通常功能相对简
   单，只包含特定的服务/App。
   这类仓库可以采用develop分支集成开发中的代码，并在该分支进行自动化构建测试。

分支策略

一共只存在两个永久分支：

1. master
2. origin/master分支的HEAD版本/tags反映了生产环境部署的最新代码。
   下面几类分支都是临时性分支，有各自的生命周期：
   • feature_v1.0.0_login
   • release_v1.0.0
   • hotfix_v1.0.0
3. feature分支来自特定功能的开发、重构和优化，在适当的时候将合回develop分支。
4. release分支从某个develop版本产生，当develop分支积累的代码适合做一次发布时，创建此 分支进行测试和bug修复。
5. hotfix分支来自线上产生的需紧急修复的bug。
6. 这几类分支都有严格的创建流程和操作规范，下面将进行具体描述。

项目操作流程

1. 创建项目：创建项目后，需要立即从master上创建永久性分支：develop ，
   将此分支推入远程仓库origin/develop，master与develop两个永久分支的权限都需设置为只允许Merge不允许Push，即代码合并必须在git网页端发起Merge Request流程
2. 开发某个功能
   分支来源：origin/develop
   新建分支名称：feature/xxx
   xxx为本分支功能名称，不鼓励一个分支中包含多个功能。
   创建分支后切换到本分支进行开发和本地测试。
   准备提交QA测试是本分支结束的必要条件。
   发起Merge Request合并回：origin/develop，模块负责人/主管负责code review
   删除origin/feature/xxx分支
3. 完成某个版本提交测试
   分支来源：origin/develop
   新建分支名称：release/xxx
   xxx为本次发布的版本名称
4. QA测试中，修复BUG： 在release/xxx的分支上进行bug修改
   在本分支中，只能修改测试产生的相关bug，其他功能调整不可在本分支修改
5. 测试完成，准备上线：
   发起Merge Request将分支分别合并回：origin/master + origin/develop
   删除origin/release/xxx分支
   master分支添加tag：X.X.X，并在描述中说明本次版本的feature内容（可根据commit message生成）