文章收录在 GitHub JavaKeeper ，N线互联网开发必备技能兵器谱

Git 使用规范

团队开发中，遵循一个合理、清晰的 Git 使用流程，是非常重要的。

否则，各种不清晰的分支结构，后续产品迭代或维护都会让人很头疼，再如果每个程序员都提交一堆杂乱无章的commit，后续的快速查找定位问题只能通过阅读代码，也是很低效的。

分支规范

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。有人把 Git 的分支模型称为它的“必杀技特性”，因为基于指针的实现使其足够轻量。

Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次，但仍要遵循一定的规范

分支命名

master 分支
- master 为主分支，也是用于部署生产环境的分支，master 分支要确保稳定性
- master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改代码
develop 分支
- develop 为开发分支，始终保持最新完成以及bug修复后的代码
- 一般开发新功能时，feature 分支都是基于 develop 分支下创建的
feature 分支
- 开发新功能时，以 develop 分支为基础创建 feature 分支
- 分支命名: feature/ 开头的为特性分支，命名规则: feature/user_module、 feature/cart_module
release 分支
- release 为预上线分支，发布提测阶段，以 release 分支代码为基准提测
hotfix 分支
- 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
- 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支

当有一组 feature 开发完成，首先会合并到 develop 分支，进入提测时，会创建 release 分支。
如果测试过程中存在 bug 需要修复，则直接由开发者在 release 分支修复并提交。
当测试完成之后，合并 release 分支到 master 和 develop 分支，此时 master 为最新代码，用作上线。

以上规范不一定是必须的，一般是根据实际情况来的，总结下自己工作中的一些问题

自己的分支一定要自测，切记不要提交后，影响到其他代码，更别说别人拉下代码还报错这种低级错误
本地分支要做到勤提交，分小功能提交，一次提交一大堆各种功能的做法也要杜绝
每天第一件事就是更新 develop 分支内容到本地分支，避免大规模 merge，太容易出错了
迭代新版本时，一定要保证当前开发分支和线上分支一样

提交规范

我们都知道，Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交，这其实就是规范，但输入的说明我们可以随便写，之前我也会随便写，被 XX 之后就，，，

$ git commit -m "hello world"

上面代码的 -m 参数，就是用来指定 commit message 的。

如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行。

一般来说，commit message 应该清晰明了，说明本次提交的目的。而且多人协作的时候，有问题也方便查看提交日志。

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

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

不管是哪一个部分，任何一行都不要有太多字符。这是为了避免自动换行影响美观。

Head

Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）。

type

type 用于说明 commit 的类别，只允许使用下面7个标识（或者用对应的 emoji 表情，在前边再加一个: 就会显示了）。

feat：新功能（✨）
fix：修补bug（