GIT 工作流
Git 作为一个源码管理系统，不可避免涉及到多人协作。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
本文介绍三种广泛使用的工作流程：
Git flow
Github flow
Gitlab flow
一、功能驱动
本文的三种工作流程，有一个共同点：都采用”功能驱动式开发”（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
二、Git分支类型
master 分支
master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。
master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。
产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。
master 分支不可删除。
develop 分支
develop 为主开发分支，基于master分支创建，始终保持最新完成功能的代码以及bug修复后的代码。
develop 分支为只读唯一分支，只能从其他分支合并，不可以直接在该分支做功能开发或bug修复。
一般开发新功能时，feature分支都是基于develop分支下创建的。
develop 分支包含所有要发布到下一个release的代码。
feature功能分支完成后, 开发人员需合并到develop分支(不推送远程)，需先将develop分支合并到feature，解决完冲突后再合并到develop分支。
当所有新功能开发完成后，开发人员并自测完成后，此时从develop拉取release分支，进行提测。
release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
develop 分支不可删
feature 分支
feature 分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
分支命名: feature/ 开头的为新特性或新功能分支，建议的命名规则: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
新特性或新功能开发完成后，开发人员需合到develop分支。
feature 分支可同时存在多个，用于团队中多个功能同时开发。
feature 分支属于临时分支，功能完成后可选删除。
release 分支
release 分支为预上线分支，基于本次上线所有的feature分支合并到develop分支之后，从develop分支创建。
分支命名: release/ 开头的为预上线分支，建议的命名规则: release/version_publishtime，例如：release/v2.1.1_20201018，含义为：版本号v2.1.1计划于2020年10月18日时发布。
release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复，上线完成后需合并到develop/master分支并推送远程。
release 分支属于临时分支，产品上线后可选删除。
当有一组feature开发完成后，首先开发人员会各自将最新功能代码合并到develop分支。进入提测阶段时，开发组长在develop分支上创建release分支。
如果在测试过程中发现bug需要修复，则直接由开发者在release分支修复并提交。当测试完成后，开发组长将release分支合并到master和develop分支，此时master为最新可发布代码，用作产品发布上线。
hotfix 分支
hotfix 分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行bug修复。
分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似，建议的命名规则: hotfix/user_createtime_hotfix，例如：hotfix/ftd_20201018_alipaybugfix，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
hotfix 分支用于线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。当问题修复完成后，需要合并到master分支和develop分支并推送远程。
所有hotfix分支的修改会进入到下一个release。
hotfix 分支属于临时分支，bug修复上线后可选删除。
三、Git flow
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
首先，项目存在两个长期分支。
- 主分支master
- 开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
下图详细介绍了其过程。
两图的意思是一样的。
Git flow的优点是清晰可控，
缺点是：
相对复杂，需要同时维护两个长期分支。
默认工作分支是 develop，但是大部分版本管理工具默认分支都是 master，开始的时候总是需要切换很麻烦。
Hotfix 和 Release 分支在需要版本快速迭代的项目中，几乎用不到，因为刚开发完就直接合并到 master 发版，出现问题 develop 就直接修复发布下个版本了。
Hotfix 和 Release 分支，一个从 master 创建，一个从 develop 创建，使用完毕，需要合并回 develop 和 master。而且在实际项目管理中，很多开发者会忘记合并回 develop 或者 master。
四、Github flow
Github flow 是Git flow的简化版，专门配合”持续发布”。它是 Github.com 使用的工作流程。
它只有一个长期分支，就是master，因此用起来非常简单。
官方推荐的流程如下。
或者是：
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
Github flow 的最大优点就是简单，对于”持续发布”的产品，可以说是最合适的流程。
问题在于：
- 版本的延迟发布（例如 iOS 应用审核到通过中间，可能也要在 master 上推送代码）
- 不同环境的部署 （例如：测试环境，预发环境，正式环境）
- 不同版本发布与修复 （是的，只有一个 master 分支真的不够用）
五、Gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
5.1 上游优先
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium项目就是一个例子，它明确规定，上游分支依次为：
Linus Torvalds的分支
子系统（比如netdev）的分支
设备厂商（比如三星）的分支
5.2 持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。
开发分支是预发分支的”上游”，预发分支又是生产分支的”上游”。代码的变化，必须由”上游”向”下游”发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
5.3 版本发布
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
六、Git日志规范
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的Commit messages可以达到3个重要的目的：
加快代码view的流程
帮助开发人员编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和feature被添加的原因
目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。建议使用如下：
Commit messages的基本语法
具体格式为:
# EN <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> # CN <类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注]
type: 本次 commit 的类型，诸如 bugfix、docs、style 等，类型说明参见下方。
scope: 本次 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject: 简明扼要的阐述下本次 commit 的主旨，是 commit 目的的简短描述，建议不超过50个字符。
body: 在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，详细的修改方法或其他需要额外重点说明的内容。
footer: 描述下与之关联的 issue 或 break change，详见案例。
Type的类别说明：
# 主要type
feat: 增加新功能
fix: 修复bug
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
Commit messages格式要求
# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档
示例：
# fix：修复支付宝支付bug
#
# 1，修复支付完成后未查询支付状态问题
# 2，增加定时任务保证支付状态完整
#
# link：http://github.com/ftd/shopmall/issue001
注：如果一次改动内容较多，包含多个提交类型时，建议拆分成多个提交，分次提交，这样会更清晰。
参考：https://blog.csdn.net/p1830095583/article/details/117135082?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_title~default-0.highlightwordscore&spm=1001.2101.3001.4242.1
