Git使用规范

项目

本规范参考gitflow模型，以解决以下开发到发布流程中可能出现的情况及问题，持续完善中

并行开发，代码互相糅合
长期任务，代码无法及时提交、更新或暂停搁置
测试阶段，其他版本的开发及测试推进
各稳定版本副本的保存以及版本回滚
临时紧急任务、版本发布后紧急修复与当前代码的冲突

Git及Gitfow相关知识

固定分支

master分支：仅存储每个上线的稳定版本，禁止提交
develop分支：开发、测试流程的主干分支，应提交完整、可发布的代码

临时分支

feature分支：由开发人员自行从develop分支创建，下一版本无法上线的特性必须创建feature分支进行开发，feature分支应通过自测正常使用后合并至develop分支等待发布
release分支：需要发布内容均提交至develop分支后从develop分支拉取并进行测试，对应开发人员针对测试反馈于该release分支进行修复改进，直到测试通过并发布，将该分支所修复的问题合并回develop分支，并提交至master分支记录版本tag
hotfixs分支：紧急上线、紧急修复分支，由当前master分支最新稳定版本拉出，修复或增加特性后提前上线，将修改合并回master分支以及develop分支

2. 流程

首先参考下图

Git使用规范
1.
概念
2.
流程
3.
规范
4.
操作示例

master、develop为两条固定存在的分支。各自开发任务应当视任务上线计划情况，于develop分支拉取feature分支进行开发，可确定于上线版本提测前快速完成的小规模任务亦可直接于develop分支进行开发。但需注意，develop分支只允许提交完整、通过自测可执行并且将于该版本发布的代码，所以建议大部分情况下开发任务独立创建分支进行开发。

2.1常规开发

更新至develop分支最新节点并在该节点拉取自己的feature分支
在feature分支完成开发，自测（可以利用个人开发环境辅助测试）
自测通过确定发布后将feature分支合并至develop分支，尚未到达提测时间可于develop分支部署公共开发环境进行预先测试
到达提测时间由负责人员于develop分支拉出release分支进行集中测试，分支成员为该版本提交发布代码的成员，未能于该时间节点的代码将延迟至后续版本发布
集中测试过程中出现的问题和优化项只在该release内进行优化、修复，直至测试通过于该分支的最终节点发布上线版本，期间可持续将修复完成的部分合并回develop分支
将release分支在测试过程中的修复和优化项合并回develop分支，并将master分支快速指向release分支的最终节点，记录该版本tag

2.2紧急发布

更新至master分支最新节点拉取hotfixs分支
在hotfixs分支完成紧急发布内容
发布并将修改内容合并至develop分支，并将master分支快速指向该hotfixes分支的最终节点，记录该版本tag

3. 规范

3.1分支命名规范

feature分支： feature-拉取日期(yymmdd)-简述
例：feature-191201-新增助代通3.0业务
release分支： release-拉取日期(yymmdd)-版本号
例：release-191210-3.2.47
hotfixs分支： hotfixs-拉取日期(yymmdd)-修复后版本号-简述
例：hotfixs-191211-3.2.47.1-修复绑定终端bug