小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
1. 前言
Git 工作流是为了上线有保障，上线过程中充分测试必不可少，良好的 Git 工作流能保障测试是渐进且可靠的，结合 CI/CD，可以全链路保障业务的快速迭代、安全上线
所以，作为开发人员，Git Flow 是必须掌握的技能
Git Flow 有不少优点
- 分支各司其职，覆盖大部分开发场景
- 预期 master 分支中任何 commit 都是可部署的
- 严格按照流程执行，出现重大事故的情形会大大降低
当然缺点也有
- 过于繁琐，无法要求所有团队成员按照这个流程严格执行
- Master 分支历史记录并不干净，只能通过打 Tag 标记哪些 Master 提交是真正要部署的版本
2. 分支管理
2.1 保留分支
1）master （主分支）
- Git主分支的名字，默认叫做Master
- 主分支一般由 develop 以及hotfix分支合并，任何时间都不能直接修改代码
- 如果想正式对外发布，就在
master分支上，对release分支进行合并，发布完成以后打上tag
2）develop（开发分支）
- 用来开发的分支，通常可以直接在其上进行开发
- 在每次发布版本
release和线上紧急bug（hotfix），需要同步到其上 - 理论上此版本只在开发阶段使用，提测时不可以直接修改， 而在测试结束后由
release分支合并到其上
2.2 辅助分支（临时分支）
1）feature（预发布分支）
- 有一组
feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支 - 如果测试过程中若存在bug需要修复，则直接由开发者在
release分支修复并提交 - 当测试完成之后，合并
release分支到master和develop分支，此时master为最新代码，用作上线 - 它的命名，可以采用
release-xx的形式
2）feature（功能分支）
- 为了开发某种特定功能，从
develop分支上面分出来的一个分支 - 开发完成后，需要重新并入
develop分支 - 一个功能的开发周期要长过本次版本开发周期， 建议开启一个
feature进行单独开发，当需要此功能的时候，只需要将feature合并入develop分支，下次一并提测即可 - 也可以同时开启多个
feature分支进行不同新功能开发，在合适的时候合并提测即可 - 功能分支的名字，可以采用feature-XX的形式命名
3）hotfix（Bug 修复）
- 软件正式发布以后，难免会出现bug，这时就需要从 master 创建一个分支，进行bug修补，这个分支就是
hotfix分支 - 线上bug修复的热补丁分支，应由
master拉出，并在修复完成后合并入master和develop保证两分支的bug已修复 - 它的命名，可以采用
fixbug-xx的形式
3. Commit 信息提交规范
一个规范的 Git 提交，包含以下三个元素
- Header - 标题，不可省略
- Body - 正文，对标题的补充，不是必须的
- Footer - 页脚，不兼容的变动，应该在页脚详细的描述，不是必须的；关闭了具体的 Issue 也应该在页脚列出
1）对于 Header 来说，格式如下
type(scope) : subject
type 只允许使用下面的几个标识
- feat : 新功能
- fix : 修复bug
- docs : 文档改变
- style : 代码格式改变
- refactor : 某个已有功能重构
- perf : 性能优化
- test : 增加测试
- build : 改变了build工具 如 grunt换成了 npm
- revert : 撤销上一次的 commit
- chore : 构建过程或辅助工具的变动
2）对于 Body 来说，自由发挥，能对标题进行补充即可
3）对于 Footer 来说，主要描述破坏性的、不兼容的修改，或者关闭的 Issue
