前端代码版本管理规范

Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git分支结构清晰，方便后续维护，总结了如下规范。

分支约定

 ├── master          # 生产分支   
 ├── release         # 测试分支
 ├── develop         # 开发分支
 ├── feature         # 若干功能分支
 └── fix             # 若干修复分支

分支命名

• 为了更好管理开发需求，所有的开发任务与仓库的issues关联
• 分支命名格式： 分支 issuesID - feat/fix - 功能简称

需求ID	功能描述	分支命名格式
1	开发登录页面	#1-feat-loginPage
2	修复登录页面	#2-fix-loginInterface

GIt提交规约

● 不要上传不相关的文件和文件夹，请使用 .gitignore进行设置
● 提交代码前请先拉取，然后再按需提交
● 不要直接上传配置文件，采用替换
● 工作目录要及时更新，不要和GIT服务器有太大的差别
● 提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交
● 提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交
● 必须保证GIT上的版本是正确的，项目有错误时，不要进行提交
● 提交时注意不要提交本地自动生成的文件
● 提交必须写注释（查看git注释）

开发分支管理

• 1. 从develop分支中切出相应的feature分支，如果同时开发多个功能，可切出多个feature分支(参考以上分支命名)
• 3. 开发完成后，开发者发起merge请求，请求将自己的feature分支合并到对应的develop分支，并提醒组长review code
• 4. 组长以及相关人员（此处可以团队内backup一起参与）执行评审过程，若有问题则需要开发者修改，修改好后提交代码到远程，提醒组长review，若无问题，则通过merge请求,将feature分支合并到develop分支。

测试流程

• 1. 开发自行完成验证后，将develop 合并至 release, 执行jekins, 发布测试环境，验证后，通知相关人员进入测试流程，验收后关闭issues。

上线流程

• 1. 测试完成后, 发布生产流程，验证完毕后，打版本tag，标签名格式：v.0.0.1_220316,录入版本明细。参考图如下：
     
     

线上bug修复

• 1. 如果线上bug不紧急，不影响用户使用，可以下个版本修复
• 2. 如果线上bug紧急，可从master分支切出一个hotfix分支用于修复紧急bug
• 3. 紧急bug修复完成后，如果需要测试，则将hotfix分支合并到对应的release分支部署到测试环境进行测试，测试完成后release分支合并到develop分支和master分支；如果确认不需要测试，则直接将hotfix分支合并到master分支、develop分支和对应的release分支
• 4. 将master分支部署到生产环境，部署好后要重新给master分支打标签