文章目录

示例

Commitizen工具

参考材料

git高级技巧

参考材料

最近在代码开发的过程中，逐渐认识到了版本管理过程中提交记录维护的重要。一个好的项目提交记录可以方便地跟踪工程历史，不必深入看代码即可了解当前commit的作用，提高项目的整体质量，更可以提高个人的工程素质。
因此，仔细学习整理了一下开发过程中git高级用法和commit规范指南，希望能用于以后的工作开发中。本博客以学习分享为目的，不足之处还请大家多多谅解。

觉得文章有收获，欢迎关注公众号鼓励一下作者呀~
在学习的过程中，也搜集了一些量化、技术的视频及书籍资源，欢迎大家关注公众号【亚里随笔】获取

git commit规范指南

commit message应该清晰明了，说明本次提交的目的。git的提交使用git commit -m "hello world"之类的来提交 commit，但是"hello world"这样的的无意见的commit无法让别人理解本次提交的目标是为了什么。
社区有多种commit message的写法规范，Angular规范是目前使用最广泛的写法，比较合理和系统化，并且有配套的工具。

commit message的作用

• 提交更多的历史信息，方便快速浏览。例如使用git log  HEAD --pretty=format:%s，可以显示上次发布后的变动，每个commit占一行，可以快速浏览某次commit的目的。
 • 可以过滤某些commit，用于快速查找信息。例如使用git log  HEAD --grep fea，可以快速查找信息
 • 可直接从commit生成change log。发布新版本时，可以自动生成change log来说明与上一个版本差异。
 • 其他优点○ 可读性好，不必深入看代码即可了解当前 commit的作用○ 为code review做准备○ 方便跟踪工程历史○ 提高项目的整体质量，提高个人工程素质
 

因此，提交commit时，遵循良好的规范是非常值得养成的习惯。

Angular规范 Commit message的格式

每次提交 ，commit message都包括三部分：header，body和footer。
形式如下，<>表示填入特定的信息：

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

其中，header是必需的，body和footer可以省略。但每部分，任何一行都不得超过72个字符（或100个字符），避免自动换行影响美观。

header

• header部分只有一行，包括三个字段○ type，必需，用于说明 commit的类别，只允许使用以下7个标识。type为feat和fix会现在change log中，其他情况可以配置。§ feat，新功能§ fix，修补bug§ docs，文档§ style，格式变化，不影响代码变动§ refactor，重构，不是新增功能，也不修改bug的代码变动§ test，增加测试§ chore，构建过程或辅助工具的变动○ scope，可选§ 用于说明commit影响的范围，简要说明修改会涉及的部分，如数据层、控制层、视图层○ subject，必需§ commit message，不超过50个字符§ 书写事项□ 以动词开头，使用第一人称现在时□ 第一个字母小写□ 结尾不加句号
 

body

• 对本次commit的详细描述，可以分成多行
 • 书写事项○ 使用第一人称现在时○ 第2行是空行○ 应该说明代码变动的动机，以及与以前行为的对比
 

footer

• footer部分只用于以下两种情况○ 不兼容变动：如果代码与上一个版本不兼容，则footer部分以BREAKING CHANGE开头，后面是对变动的描述，以及变动理由和迁移方法○ 关闭issue：如果当前commit是针对某个issue，可以在footer部分关闭这个issue，可依次关闭多个issue, Closes #123, #245, #992
 

revert

• 当前commit是用于撤销以前的commit，必须以revert开头，后面跟着被撤销commit的header
 • body部分格式固定：This reverts commit 	
 

如果当前commit与被撤销的commit在同一个release里面，那么它们不会出现在change log里面。如果两者在不同的release里，当前commit会出现在change log的reverts小标题下面。

示例

angular.js的提交示例

Commitizen工具

大量的代码提交，必然会产生大量的commit log，而每一次commit是阶段性的ending，应记录着这一阶段所完成的事以及关注点，尽可能详细具体。
上面介绍了Angular目前的commit规范，一般来说在写git commit 时，按规范进行填写即可。不过也有命令行工具提供了step by step的引导——commitizen。
commitizen是一个格式化commit message的工具。代码commitizen后，提交commit mesage时，不再使用git commit -m方法，而是git cz，会出现交互式选项，给你一个完善的commit message。

commitizen配置

我主要关注在非node项目下，使用commitizen。
1. 首先安装node.js
2. 安装git-cz：npm install -g commitizen git-cz
3. 安装changelog，生成changelog的工具：
npm install -g conventional-changelog
npm install -g conventional-changelog-cli
4. 进入项目目录，执行：npm init --yes，会生成项目对应的package.json，将项目目录下产生的package.json的内容写入到自己建的package.json（/User/Elite/package.json）中，如果有多个项目，将各项目生成的package.json内容写入到package.json中，配置（/User/Elite/package.json）。我试了一下，init生成的node_modules和package.json删除，也可以运行
5. 支持angular的commit message格式：commitizen init cz-conventional-changelog --save --save-exact
6. 生成changelog:conventional-changelog -p angular -i CHANGELOG.md -s

参考材料

- https://segmentfault.com/a/1190000009048911
 - https://www.jianshu.com/p/36d970a2b4da
 - https://www.jianshu.com/p/d264f88d13a4
 

git高级技巧

git作为开发者必备技能，除了日常使用的git add, commit, push, pull, fetch, merge, checkout等基础命令，还有一些比较有用好玩的命令。

git rebase

rebase也称为变基，它是合并来自不同分支修改的另一种方法。git rebase [basebranch] [topicbranch]命令将特性分支topicbranch变基到目标分支basebranch，即将topicbranch分支上的修改在二者的公共快照上重演一遍。
合并分支最容易的方法是merge，如下图所示，它会把两个分支的最新快照C3和C4以及二者最近的共同祖先C2进行三方合并，合并的结果是生成一个新的快照，并提交 。


另一种合并的方法就是变基：提取在C4中引入的补丁和修改，然后在C3的基础上应用一次。可以使用rebase命令将提交到某一分支上的所有修改都移到另一分支上，就像重新播放一样。变基的原理是首先找到两个分支（如当前分支experiment、变基操作的目标基底分支master）的最近共同祖先C2，然后对此当前分支相对于该祖先分支的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底C3，最后以此将之前另存为临时文件的修改在C3上重新应用一遍。

rebase使得提交历史更加整洁，尽管实际的开发工作是并行的，但它们看上去是串行的，提交历史是一条直线，没有分叉。
rebase的两大使用场景分别是合并分支、修改commit:

git cherry-pick

可以把某几个commit“摘“出来到一个新的分支，可以使用cherry-pick。

git grep

grep是查找检索功能，如git grep ‘Long userId’，可以查找项目中的所有’Long userId’

git stash

当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转移到其他分支上进行一些工作。但是你不想提交进行了一半的工作，否则以后你无法回到这个工作点，这些就可以使用git stash命令。
即如果你修改了本地仓库但不想提交commit，此刻需要切换到别的分支，就直接使用git stash

参考材料

- https://www.dazhuanlan.com/yzbdxiangyata/topics/1101684
 - https://www.progit.cn/#_rebasing