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 是必需的，Body 和 Footer 可以省略。
Header
格式：<type>: <subject>
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端的开发，总觉得该沉淀沉淀啦，总结积累的开发经验。
文中所说不一定完全对，欢迎大家拍砖，我一定虚心接受，互相讨论！
