公司Git使用规范

背景

为规范公司内部研发使用Git的流程，特出具此文档。

代码功能新增 & Bug修复的流程

分支创建

# 切换到主分支
git checkout master 
# 更新代码到最新
git pull 
# 基于master分支拉取新的功能分支
git checkout -b feature/task_title_change

功能开发

开发同学根据实际业务需求，将业务代码编写完成，自测验证后视为此阶段完成。

代码提交

# 查看工作区状态，防止提交不必要文件，或者少带文件
git status 
#此处最好使用gui工具填写提交，下方会给出文档
git commit -m "代码内容描述" 
# push到远程仓库
git push -u origin feature/task_title_change

测试分支维护

目前瓦力维持单环境，不需要创建测试分支，但是需要保证测试分支符合生产环境最新代码。

当测试环境基准代码与生产环境代码不对应时，可删除test分支重新拉取。

合并代码到测试分支

# 切换到测试分支
git checkout test
# 更新代码（养成习惯）
git pull
# 合并代码，将功能分支代码合并到测试分支上
git merge feature/task_title_change
# 提交代码
git commit -m "代码内容描述" 
# push到test分支
git push

代码更新

后续完善好devops，不需要人工操作进行代码更新。

当前根据以往操作方式进行操作。

当测试环境部署后，由产品主导，在群内告知大家修改点和影响点，通知大家进行一起进行测试验证。

Bug修复

如在测试流程中，发现有bug，此时应当切回开发分支进行修复，修复完成后再次合并到测试分支。

请注意，测试分支需要时刻保持与生产环境代码对应，不得产生测试环境代码落后于生产环境版本的情况。

测试通过，提交合并请求（合并到生产分支）

当前生产分支master无需审批和code review，此为后续规划，规划执行前自行merge。

此项操作为将开发分支合并到master上。

如果遇见不能自动解决的合并冲突，请从master拉取新的合并分支merge/20220320，将开发分支代码合并到合并分支上，并解决合并冲突。

解决冲突后再将合并分支合并到master上。

新增版本号

对于每一个生产环境的代码版本，我们需要进行打tag的操作。

登录云效平台，进行打tag的操作，tag命名规范见下文。

当tag添加完成后，在无运维人员情况下，联系对应负责人员，将代码更新到生产环境。

版本号设置规则

当该次版本发布为迭代计划时，增加一个大版本，比如原有Tag为v2.0.4 ，此时完成一次大迭代要进行发布，tag应该为v2.1.0
当该次版本发布为一个版本计划时候，增加一个主版本，比如原有Tag为v2.1.0，此时更新后为v3.0.0
当该次版本发布为一个bug修复或者小调整的时候，增加一个小版本号，比如原有Tag为v3.0.0，此时更新后为v3.0.1
tag创建时，需要详细描述本tag所涉及的变更。

发布成功

当功能需求或bug修复成功上线，生产环境验证通过后。

请将master分支合并到test分支上，以保证test分支的最新。
通知产品更新changelog，也就是产品变更文档，发布更新通知

分支命名规范

开发分支默认以feature/开头，后接尽量详细的分支修改功能名称
bug修复分支以bugfix/开头，后接尽量详细的bug修改名称
测试分支在目前单测试环境情况下，保持使用test单分支
生产环境分支保持为master

Tag命名规范

生产环境的Tag，默认以大写的V开头，比如V1.0.0
当属于功能变更类型或有较大变更的优化类型代码上线，我们增加一个大版本号，变为V1.1.0
当属于bug修复，小调整不涉及功能变动的代码上线，我们增加一个小版本号，上上面的基础上V1.1.1

CommitMessage规范

提交文案需要详细描述本次提交所涉及的功能变更点，根据瓦力现状，我们每次提交，Commit message 都包括两个部分：header，body 。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

Type

type用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

Scope

scope用于说明 commit 影响的范围。

比如：PC，小程序，APP，PC客户端，所有客户端

Subject

subject是 commit 目的的简短描述，不超过50个字符，相当于一个简要描述。

Body

Body 部分是对本次 commit 的详细描述，可以分成多行。

下面是一个完整的CommitMessage范例。

feat(PC端):调整了PC端订单相关的功能

这里可以写一点项目背景，为啥要做这个事情，甚至可以贴上prd的链接，和谁一起开发的。下面写具体的代码变更点
1. 改了逻辑A
2. 改了页面B
3. 改了按钮C

Ye来说

Git使用规范