GIT基本规范

Git规范

所有使用项目，必须严格按照规范操作，否则不予合并代码、提测、打包上线等后续操作。

基本要求

1. 所有commit必须要有注释，内容必须按照注释格式严格执行，
2. 合理控制内容提交的颗粒度，一次commit含一个独立功能点，禁止一次提交涵盖多个功能项目，
3. 正确为每个项目设置提交用到的user.name信息，不可随意设置无法识别的信息。

版本号（tag）

1. 版本号命名规则：主版本号.次版本号.修订版本号，（遵循github语义化版本命名规范），
2. 版本号仅标记master分支，用于标记某个可发布/回滚的版本代码，
3. 对master标记tag意味着该tag能发布到生产环境，
4. 对于master分支代码的每一次更新(合并)必须标记版本号，
5. 仅项目管理员有权限对master进行合并和标记版本号

项目权限

1. 浏览者(Guest)只能浏览代码，无push、pull request等所有写权限
2. 开发者(Developer)拥有浏览、push非主分支、提交pull request工单权限
3. 管理员(Master)拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限

分支使用

1. 每个Git项目固定含有上述所有分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。
2. 功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉取hotfix分支。

代码提交

1. 一个提交就代表解决一个问题
2. 大问题适当地分解为多个小问题，以便每次小型提交都更易于理解

代码合并

1. 将开发完毕的分支，拉取develop最新代码，merge并解决冲突后，之后在对应的feature分支创建并提交到develop分支，并自动触发merge request请求，然后进行code review，确认无误后再合并。

（每个merge request不要包含不相关的功能；merge request提交后需要及时跟踪动态，包括通过、打回等；该功能进入提测流程后，需删除之前的功能分支）

注释格式

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

其中，Header 是必需的，Body 和 Footer 可以省略。不管是哪一个部分，任何一行都不得超过72个字符。这是为了避免自动换行影响美观。

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

type用于说明 commit 的类别，只允许使用下面7个标识。
feat：新功能（feature）
fix：修补bug

docs：文档（documentation）

style： 格式（不影响代码运行的变动）

refactor：重构（即不是新增功能，也不是修改bug的代码变动）

test：增加测试

chore：构建过程或辅助工具的变动

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

subject是 commit 目的的简短描述，不超过50个字符。

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

Body
Body 部分是对本次 commit 的详细描述，可以分成多行, 有两个注意点:

使用第一人称现在时，比如使用change而不是changed或changes;

应该说明代码变动的动机，以及与以前行为的对比;

Footer
Footer 部分只用于两种情况:

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法;

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue (Closes #123, #245, #992), GitHub这个功能很好用；

Revert

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。