git工作流及commit规范

---

Git 是目前最流行的源代码管理工具。可以方便的维护和管理团队合作项目。

但若没有一个合理，规范的分支命名和管理，以及commit消息的编写，会使得仓库越来越臃肿，也难以看懂历史变更，版本发布，bug修改等。

上周自己向主项目仓库提交了一个pull request，说句实在话，commit消息杂乱无章，重复commit，而且还混带了其他人的commit消息等等，真的干扰到主项目的管理和维护。

鉴于此，LZ查阅了一些网上的资料，以及自己亲手实践测试，写下这篇文章，来规范自己以后的git工作流程，如果万幸的话，还能给其他开发者一些参考。

这里先给大家安利一篇好文 Git 分支管理最佳实践，LZ也主要参考了该文章。

基于git flow的项目流程

文字叙述可能有点啰嗦，直接上图比较直观

点击看大图

流程图详解

说明：
upstream : 远程主项目仓库
origin : 远程个人仓库
local : 本地仓库
仓库指向的白色框，代表该仓库下的分支

• 关系建立
  1、fork主项目到个人的远程仓库
  2、将fork下来的项目clone到本地
  3、git remote add upstream 建立与主项目远程仓库的关联
• 开发某功能xxx
  4、项目管理者在主项目仓库新建分支 feature/xxx
  5、将新分支同步到本地dev
  6、git checkout -b feature/xxx 建立本地对应功能分支
  (此时本地的dev和feature/xxx分支与upstream上的分别对应相等)
  新功能开发完成后，测试通过后
  7、push到远程仓库
  8、提交pull request
  9、合并该分支并删除

commit提交规范

关于commit信息，它并没有固定的格式，但是每次的commit信息应当是简洁明了的表达你的修改，让其他合作者很容易的看懂。

就目前来看，最受欢迎，使用最广泛的就是 Angular规范，如下图

Angular.js

在Angular规范中，将commit message规定了三部分，分别是

• Header
• Body
• Footer

在你的commit信息中，Header是必须的，而后面两种可加可不加，LZ个人认为只需Header即可，简洁明了，commit太复杂了反而不好。所以这里只介绍一下Header部分怎么写，其余两部分可以移步 Angular规范 看官方详细的说明。你也可以参考Angular.js开源项目的commit

Header

Header只需一行，包括type，scope，subject，格式如下

type(scope): subject

1、type(必选)
type 用于说明你commit的类型，有如下7种

• feat：新功能 (feature)
• fix：bug修复(bug fix)
• docs：文档相关 (documentation)
• style：代码格式 (formatting, missing semi colons, …)
• refactor：重构
• test：添加测试(when adding missing tests)
• chore：工具或维护变动 (maintain)

2、scope(可选，建议选择)
scope用于表明你此次提交改动的范围和地方。当你找不到合适的词表明此次改动时，可以填上*

3、subject(必选)
简短的文本来描述你的改动

• 动词开头，第一人称，如change，不要写changed或者changes
• 第一个字母不要大写
• 不要以句号( . )结尾

备注：如果某次commit是为了fix某个issue，那么要在Footer部分加上

Close #123

或者关闭多个

Closes #123，#456

Revert

是专门用来撤销上一次commit的操作，格式如下

revert: <被撤销的commit的Header部分>
This reverts commit <被撤销commit的SHA标识符(git log查看)>