Git指南 - 通过规范使用Git来证明你是一个牛牛

在工作中，你的队友看到你在用Git时，如何辨别你是个老手，还是新手?

关联篇

• Git指南 - 你该掌握的那些基础认知和首次配置
• Git指南 - 项目实战中天天用的那些基础命令
• Git指南 - 通过规范使用Git来证明你是一个牛牛
• Git指南 - 我经常遇到的那些项目实战场景
• Git项目实战 - 我遇到的那些Git问题是这么解决的

通过以下几个方面的理解 → 证明你经常使用Git管理项目

1. 分支管理（保护）：多分支的意义所在，每个分支都有自己存在的意义，防止造成分支污染
2. 流程规范：多人协同开发中总会遇到各种问题，掌握一种良好的习惯能避免很多坑
3. commit规范：这个就像我们代码的见名知意，他不一定能体现你多么厉害，但是可以告诉别人你的专业素养，所以要有统一规范
4. 操作方式：你是用Git命令，还是Git附属工具（命令逼格高点，因为工具的本质执行的也是命令 - 自我感觉）

分支管理

一般我们最少会有2-3条固定分支，及生产分支、测试分支、开发分支

创建项目时，需要根据不同环境创建三个常设分支：

1. develop：开发环境的稳定分支，公共开发环境基于该分支构建；
2. pre-release：测试环境的稳定分支，测试环境基于该分支构建；
3. master: 生产环境的稳定分支，仅用来发布线上新版本，除了从pre-release或生产环境bug修复分支进行merge，不接受任何其它修改

流程规范

正常流程

1. 从develop分支切出一个新分支，根据功能还是bug，命名为feature-*或fix-*;
2. 开发者开发完成，提交分支到远程仓库；
3. 开发者发起merge请求（在gitlab页面点击“创建合并请求”），将新分支请求merge到develop分支，并提醒code reviewer人员进行review；
   4. code reviewer对代码review之后，若无问题，则接受merge请求，新分支merge到develop分支，同时可删除新建分支；若有问题，则不能进行merge，可close该请求，同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程；
4. 提测时，直接从当前develop分支merge到pre-release分支，重新构建测试环境完成提测；
5. 测试完成后，从pre-release分支merge到master分支，基于master分支构建生产环境完成上线。并对master分支打tag，tag名示例：“v1.0.0_2019032115”版本号_上线时间（上线时间精确到整点）
   流程示意图如下所示

并行开发、测试环境bug - 修复流程

并行开发：前一个版本已经提测但未上线，后一个版本又已在开发中并部分合并到了develop分支，提测后测试环境发现bug需要修复，但是develop分支此时又有新内容且该部分内容目前不计划提测

此时可以从pre-release切出一个bug修复分支。完成之后需要同时merge到pre-release分支和develop分支。merge时参考“正常开发流程”。

流程示意图如下：

生产环境bug - 修复流程

生产环境的Bug分两种情况：

1. 紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为；
2. 非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复；

非紧急Bug修复参考“正常开发流程”，同常规版本迭代开发一致。

紧急Bug修复，需要从master分支切出一个bug修复分支，完成之后需要同时merge到master分支与develop分支（如果需要测试介入验证，则可先merge到pre-release分支，验证通过后再merge到master分支上线）。merge时参考“正常开发流程”。

流程示意图如下：

---

commit 规范

通用：commit 规范

往往我们commit提交备注时均会写明已做工作，但是为了更有效且快速的区分提交内容，网上早已有一个规范，这里直接记录一下，用于提升自己 ~

type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature~ 所有的type类型如下：

• feat(常用)：新增 feature
• dev(常用)：新增功能（我自用此标签，等同 feat）
• fix(常用)：修复 bug
• docs：仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
• style：仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
• refactor：代码重构，没有加新功能或者修复 bug
• perf(常用)：优化相关，比如提升性能、体验
• test：测试用例，包括单元测试、集成测试等
• chore：改变构建流程、或者增加依赖库、工具等
• revert：回滚到上一个版本

规范之后，以下为俩个适用的命令

• 提供更多的历史信息，方便快速浏览

$ git log <last tag> HEAD --pretty=format:%s

• 可以过滤某些commit（比如文档改动），便于快速查找信息

$ git log <last release> HEAD --grep feature

当按一定规则去整合git的时候，可以生成一个对应的一个文档，在github有这样一个项目
↓↓↓
接入参考commit-message-test-project→→→项目地址

---

以下仅为2022年入职新公司要求的提交规范

2022：commit 规范

1.feat：新增功能 通过#跟上在本公司提出新功能及其bug的工具（禅道、redmine）中的编号例如（#1234）1234就是编号.
如图:

2.fix：解决bug #跟上redmine 中的bug编号 #1255
如图:

3.pref：意思是新需求 后面加上需求的介绍就ok了、例如（pref：新加了一个提交页面）
4.other：其它 就是除了以上的问题 例如 （other：修改button样式）
如图:

---