git规范与日志规范

因为要分享git规范,所以今天也顺便做一个总结，这个仅限于对git的开发中和部署时的规范和提交时的日志规范做总结。本文章分两个部分总结git规范，一个是从分支讲解在开发

目录

git提交规范-commit message

分支构成

master和develop分支一直存在，且名称不会变化，一般不直接修改这2个分支，由其他分支合并而来。

feature、release、hotfix分别用于功能点开发、优化，特定版本测试，线上问题紧急处理，同一类型的分支会产生多个。

分支划分如下：

• master：与线上版本保持绝对一致；
• develop：开发分支，由下文提到的release、feature、hotfix分支合并过后的代码；
• feature：实际功能点开发分支，建议每个功能新建一个feature， 具有关联关系的功能公用一个feature分支；
• release：每一次开发完成之后，从develop创建出来的分支，以此分支为基准，进行测试；
• hotfix：该分支主要用于修复线上bug；

命名规范约定如下：

• feature分支命名：feature/name
• release分支命名：release/name
• hotfix分支命名：hotfix/name

比如有一个「优化分布式Session」的需求，可在develop分支的基础上创建新分支 feature/optimize_distributed_session进行开发，开发完成后合并到develop分支。

分支详细介绍和处理流程

1 永久分支：Master分支与Develop分支

解说: 
 

主分支，与线上运行的版本始终保持一致，任何时候都不要直接修改master分支。一个版本的release分支、hotfix分支开发完成后，会合并代码到master分支，也就是说master分支主要来源于release分支和hotfix分支。
开发分支，始终保持最新完成以及bug修复后的代码，新增功能时基于该分支创建feature分支。一个版本的release分支、hotfix分支开发完成后，也会合并到develop分支，另外，一个版本的feature功能开发完成后，也会合并到develop分支。也就是说develop分支来源于feature、release、hotfix分支。

Feature 分支
分支名 feature/*
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留
解说
开发新功能或优化现有功能时，会创建feature分支，以develop为基础创建。一般会有多个功能同时开发，但上线时间可能不同，在适当的时候将特定的feature分支合并到develop分支，并创建release分支，进入测试状态。

Release分支

分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
解说:
当一组feature开发完成，会首先合并到develop分支，开始进入提测阶段时，会创建release分支。以release分支代码为基准提测，测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

维护分支 Hotfix

分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
解说:
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。

特殊情况

1. develop分支已存在未上线的feature代码, 此时需要紧急上线一个新功能, 但develop的代码不能上，如何处理 ？
   • 以master为基线创建feature， 在完成之后，代码合并到master分支；
   • 为了保证develop是最新代码，需要从master合并到develop分支；
2. 以develop为基线，创建了f1和f2两个feature分支之后, f1,f2开发一半的时候，发现两个分支代码需要有依赖怎么办 ？
   • 最好在开发开始前确定两个功能是否相关,若相关则只创建一个分支,两个功能在一起开发;
   • 如果已经创建，则需要合并到一个分支；
   注意: 一定要保证commit历史记录的整洁，代码合并时，根据情况选择merge或rebase;使用rebase注意，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作；

git提交规范-commit message

Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。
使用Angular的Commit message 格式。也有配套的工具(自行选择)
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits

$ git commit -m "hello world"
 

上面代码的-m参数，就是用来指定 commit mesage 的。
如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行。
一般来说，commit message 应该清晰明了，说明本次提交的目的。
Git上随便打开一个git的源码,比如spring boot的就可以看到那些提交记录

commit message 格式

每个commit message 包括header,body和footer，各占一行。其中header由type、scope和subject组成。header必须要写，header的scope是可选的。Body 和 Footer 也以省略。

(): 
 //空一行
 
 //空一行

每行不超过100字符也有72个的,原因,为了美观

Header

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

Type

必须为下列之一:
• feat：新功能（feature）
• fix：修补bug
• docs：文档修改
• style： 不影响代码含义的修改(例如：white-space; 格式化等)
• refactor：重构（即不是新增功能，也不是修改bug的代码变动）
• perf: 提升性能的修改
• test：增加或修改测试
• chore：构建流程或辅助工具的变动

Scope

scope用于说明commit修改的范围，比如数据层、控制层、视图层,route, component, utils, build等等。如果修改影响多处，可使用"*"。

Subject

Subject是对修改的简要说明：
• 使用祈使语气，一般现在时。
• 首字母小写
• 句末不要使用句号

Body

使用祈使语气，一般现在时。另外，body需要包含修改的原因和与之前版本的区别。

Footer

任何Breaking changes的信息或者关闭issue的信息都可写在Footer. Breaking changes需要以 BREAKING CHANGE: 开头。
如下为我的2条提交记录：

commit 9fb447d73c637cfa128b57a84d95dc72bb14412b (HEAD -> master)
 Author: zhongjx 
 Date:   Wed Dec 26 18:22:53 2018 +0800refactor(*): 使用prettier格式化代码使用eslint+prettier取代之前的eslint+airbnb规范commit a4a5e9259d5dd4f5f4d3d16fea3392df2a877ee1 (origin/master)
 Author: zhongjx 
 Date:   Tue Nov 20 09:49:27 2018 +0800chore: 添加commit msg格式要求

Revert
如果commit用于撤销之前的commit，需以revert:开头，接着写被撤销的commit的header。body里要写：this reverts commit . hash为被撤销的commit的hash值。这种格式也可以由git revert命令自动生成。