git规范细则

git规范细则

对于Git的提交日志，我们有非常明确而详细的提交规范。这将有助于我们在查看 项目历史时， 更容易明确每一次提交的内容。

提交消息格式

每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式，包括修改类型、影响范围和内容主题：

修改类型(影响范围): 标题
<--空行-->
[正文]
<--空行-->
[页脚]

标题是强制性的，但标题的范围是可选的。

提交消息的任何一行都不能超过100个字符！这是为了让消息在GitHub以及各种Git工具中都更容易阅读。

修改类型

每个类型值都表示了不同的含义，类型值必须是以下的其中一个：

• feat: 提交新功能
• fix：修复了bug
• docs：只修改了文档
• style：调整代码格式，未修改代码逻辑（比如修改空格、格式化、缺少分号等）
• refactor：代码重构，既没修复bug也没有添加新功能
• perf：性能优化，提高性能的代码更改
• test：添加或修改代码测试
• chore：对构建流程或辅助工具和依赖库（如文档生成等）的更改

代码回滚

代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit ”，其中“”是要还原的那个提交的SHA值。

影响范围

范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。

当修改影响多个范围时，也可以使用“*”。

标题

标题是对变更的简明描述：

• 使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
• 不要大写首字母
• 结尾不要使用句号

正文

正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。

页脚

任何Breaking Changes（破坏性变更，不向下兼容) 都应该在页脚中进行说明，它经常也用来引用本次提交解决的GitHub Issue。

Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。

git 使用流程规范（merge-request)

如今很多项目都采取merge request方式来进行codereview，所有掌握merge request很有必要，步骤如下：
1.现在本地用创建一个本地分支，比如叫xx_branch。
2.改动xx_branch你需要改动的代码。
3.进入你的项目根目录下，运行如下命令，将xx_branch推到远程分支。
git add .
git commit -a -m ‘xxxxx’
git push -u origin xx_branch
4.在gitlab上面操作，进入xx项目下，点击merge request选项，然后选择你之前推到远端的xx_branch和你要合并到哪个分支，比如你要合并到master上。
5.点击merge request。

git解决冲突

1. git stash 
2. git pull
3. git stash pop
4. 解决冲突
5. git pull

代码合并

1.单分支合并

git stash 
git pull
git stash pop
# 合并冲突并进行提交
git push

2.多分支合并

# 将my_feature合并到develop
git clone -b my_feature ***
git checkout -b develop
# 将本地的develop追踪远程的develop
git branch --set-upstream-to=origin/develop develop
git pull
# 合并解决冲突，进行提交
git push

分支删除

# 删除本地分支
git branch -D $branch_name

# 删除远程分支
git push origin --delete $branch_name