Git的使用规范

前言

个人使用git也快4年的时间了，从开始的pull&push分不清，到慢慢的注重使用规范，使用效率，再到在团队协作规范，个人总结了一套自己的想法，不一定都对，希望给大家一些参考。

初始git

git从一出来就伴随着和svn的比较差异，个人觉得他们最大的差异是以下几点：

git有各自的本地仓库，svn只有一个中央仓库
git具有强大的分支管理，这点是svn无法媲美的
git的每次commit保存的是文件之间的diff，svn则是全量保存

git常用的命令

git的命令实在是太多了，有很多可能我们永远都用不上，作为一个工具，我们应该将其基本命令做到熟练使用就可以啦。
下面列出我常用的一些命令：

pull
push
add
commit
status
fetch
branch
checkout
diff
log
merge
rebase

如果小伙伴还不知道上述命令的具体的含义，得去好好补补课啦！
更多详细的git说明，请点击查看

git客户端

进行git操作可以使用命令行终端，或者使用客户端（如SourceTree）。个人建议绝大部分操作都在命令行终端进行，如pull、push、commit、checkout等操作，少部分操作在客户端进行，如查看每次提交的diff或者整体分支线。

在命令行操作git，你会更好的把握每次操作都做了些什么。为了更高(zhuang)效(bi)的操作git，有个小诀窍是你必须掌握的：alias（设置别名）。

下面是我常用的alias配置：

ci = commit
st = status
co = checkout
br = branch
ss = status --short
df = diff
dc = diff --cached
lo = log --oneline
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

最后lg这个最屌了，我也是从别处学过来，具体啥效果，大家试试就知道了
alias的配置没有最佳的，配置符合自己习惯的即可
更多alias配置可参考

git基础就一笔带过了，更多的细节网络上有许多的相关文章，相信大家都能找到自己想要的！

git分支使用规范

下面要说的是自己在团队内推行的一套多人协作的git分支使用规范，这也是大部分团队在用的一套分支规范。

分支规范图示

上述图，相信大部分人都见过，但不一定理解了，我就根据自己的使用总结如下：

一个稳定master分支
一个待发布的develop分支
若干个正在开发的feature分支
分支合并前先rebase待合并的分支
分支合并使用merge —no—ff，生成合并记录
可以使用gitlab的pull request进行合并前的code review
如遇到线上有一般的bug，可在develop上切换出hotFix分支进行bug修复，完成后合并到develop上，等下次版本一起发布
如遇到线上有十分严重bug，应在master上切换出hotFix分支进行bug修复，并验证好了后随即合并到master上准备发布
版本发布后可以按需切换出版本分支（release-v1.0）或者使用tag进行代替

commit规范

commit示例

上述两幅图，都是我不同时期的commit记录，相信大部分人都会觉得右图中的commit要好些吧！

哈哈哈，下面开始提问环节

什么样子的commit才算好的呢？

保证commit尽量只做一件事
书写commit message言简意赅
规范commit message格式

为什么要规范commit message？

加快Code Review 的过程
可以快速生成release note
让其他的程序猿找历史问题的时候想跪谢
帮助提高项目的整体质量

那如何规范commit message呢？

这个问题问的好啊，我们要规范commit，首先是不是应该要全面剖析commit呢！

commit全面剖析

提交信息包括三个部分：Header，Body 和 Footer。



其中，Header 是必需的，Body 和 Footer 可以省略。

Header

格式：: 
type：用于说明 commit 的类别，如：feat、fix等
subject：本次commit的简短描述，以及物动词开始，15个字内

Body

Body 是对本次 commit 的详细描述，可以分成多行。
注意：应该说明代码变动的动机，以及与以前行为的对比。
无重大变更，一般不写。

Footer

Footer 一般只用于以下几种情况
- 关联 Issue（Issue #1, #2, #3）
- 关闭 Issue（Close #1, #2, #3）
可用github关闭issue，或者与自己的任务相关联

说了这么多，我也知道了要规范commit message，但是难道我们每次commit的时候都手动输入，达到上述右图中的效果么？
很明显不是啦，这样子做根本就体现不出我们是程序猿的懒。
下面到了推出解决方案的时候了

git cz插件

根据github上相关提示进行安装
git cz插件
插件安装完成之后，输入git cz能出现以下效果就说明你装成功了

安装成功效果图

都是些简单的英文，大家都看的懂，我就header中type进行简单说明：

feat：完成一些功能
fix：修复一些问题
docs：一些文档修改
style：样式修改
refactor：一些无关功能性的修改，例如重命名
perf：一些优化重构
test：测试相关提交
chore：引入一些第三方库等

总结

本文将个人的git使用经验进行了初步总结，对你而言有好有坏，如其中有部分能帮组你，就十分高兴了！

后记

此篇博客算是我再次踏上书写博客之路的第一篇，期望自己能坚持下去，达到每月能有2-3篇博客的产出。
本人有4年以上的移动端开发经验，目前主要做Android端的开发，总觉得该沉淀沉淀啦，总结积累的开发经验。
文中所说不一定完全对，欢迎大家拍砖，我一定虚心接受，互相讨论！