Git工程化最佳实践

1. 本文导读

本文对应的 git-standardize 项目地址 https://github.com/vimerzhao/git-standardize

1.1. 问题背景

大部分程序员对于Git的理解还停留在

git add .
git commit -m "update"
git pull
git push

的阶段，但这在实际项目开发中是远远不够的。
举一个简单的例子，现在我们需要过滤所有修复bug的提交，该怎么做？显然是无法做到的，因为无法从commit信息获知。但是，如果我们在每次commit信息里面都注明提交的类型，是不是就可以通过过滤指定类型来达到目的了。
再举一个例子，如果我们的分支命名都是

master-01
master-02
feature-add_sd_card_permission
bugfix-id-342141
bugfix-authorize-error

这种格式，我们是不是很不方便去做 定位分支的负责人，过滤指定分支 等操作，更不用说视觉上的混乱所造成的困扰了。
再比如，笔者近来发现某个仓库有大量构建产生的中间文件，究其原因，发现是因为管理人员设置的 .gitignore 配置如下

....
/build
....

显然，这种写法无法忽略子模块的 build 目录。

基于以上三个例子，Git使用的工程化、标准化是十分必要的。
我们所谓的造轮子，亦不仅仅存在于编程中，日常工作中常有大量的重复工作，亦是一种轮子，本文即 希望规范化、流程化Git的使用 ，以期提高开发者的效率。
本文基于作者工作中的教训和思考积淀而成，虽曰“最佳”，但也只是现阶段我心中的最佳实践，仅供参考。

1.2. 阅读须知

Git的作者Linus也是Linux的作者，Git最初也是Linux内核开发者在使用，所以其本身的配置和使用也是充满了类Unix的味道，诸如别名、命令、配置文件等等，都是Unix/Linux开发者习以为常的东西，但对于客户端、大前端的开发者可能相对陌生，所以，继续阅读本文之前，希望你对以下知识至少是有了解的

• 基本的Shell命令： alias / source / grep 等

• 终端的基本使用，如通过 Tab 键可以自动补全命令

• 配置文件的使用，如Bash的 .bashrc / .bash_profile ， zsh 的 .zshrc ，Git 的 .gitconfig ，他们的原理都是相似的

2. 仓库创建

无论是Github还是工蜂，我们新建一个Git仓库后，往往会出现以下提示：

某种意义上，这幅图会带来很多误解，我们在创建一个Git仓库后还有很多事情要做，一开始，我们或许习惯于渐进式的改进，但我们应该意识到这种工作是可以 流程化、自动化 的，即不要等到发现问题再去解决，而应该一开始就建立有效、可复用的机制。

2.1. 信息配置

使用 git config 配置必须要的用户信息

反面案例：