直接回答：Git Flow 的核心是：master 只保留随时可发布的版本、develop 是日常集成分支，功能在 feature 分支开发、发布走 release、线上紧急问题走 hotfix，任何人都不直接往 master 提交。
分支管理
分支策略如下
master 分支和 develop分支
master 分支
master 分支时常保持着软件可以正常运行的状态。由于要维护这一状态，所以不允许开发者直接对master 分支的代码进行修改和提交。
release分支的开发工作进展到可以发布的程度后，将会与master分支进行合并，并且这一合并只在发布成品时进行。发布时将会附加版本编号的Git标签。
develop分支
develop分支是开发过程中代码中心分支，也是代码最全的分支。与master 分支一样，这个分支也不允许开发者直接进行修改和提交。
开发人员要以develop分支为起点新建feature 分支，在feature 分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码，以便开发人员创建feature分支进行自己的工作。
在feature 中工作
feature 分支以develop分支为起点，是开发者直接更改代码发送提交的分支。开发流程：
- 从develop分支创建feature分支（命名规则:feature/功能名称或开发人员姓名）
- 从feature分支中实现目标功能
- 通过Gitlab 向develop发送pull request，或者将开发分支pull到gitlab
- 接受其他开发者审核后，将Pull Request合并至develop分支，或者有主开发人员手动合并。
更新本地的develop分支
我们发送的pull request 在gitlab 端与develop 合并后，为了让其反应到本地的develop分支中，我们需要进行以下操作：
- 切换到develop分支
- 执行git pull (fetch & merge)
每当需要从develop分支创建feature等分支时，记得一定要先执行上述操作，保证develop分支处于最新状态。
release分支
创建 release分支(命名规则release/发布的版本号) ，在这个分支，我们只处理与发布前准备相关的提交*，比如版本编号变更的元数据的添加工作。如果软件部署到预演环境后测试出bug，相关修正也要提交到这个分支。
注意：该分支绝对不能包含需求变更或者功能变更等重大修正。这一阶段的提交数应该限制到最低。理想情况是从develop创建release分支之后是没有问题的，就可以直接打tag，合并进main分支。
下述情况需要创建 hotfix 分支
- release 版本中发现了bug 或者漏洞
- develop 分支正在开发新功能，无法面向用户进行发布
- 漏洞需要及早处理，无法等到下一次版本发布
从上往下，先触发哪个规则就用哪个分支创建合并方法
- main分支有bug，就从main创建hotfixes分支，合并进develop和mian分支。
- release分支有bug，从release分支创建hotfixes分支，合并进develop和release分支。
- develop分支有bug，直接在开发分支修复，修复后合并进develop分支。
修复完成后可以在合适的时机删除掉hotfixes分支
commit提交规范
1 | 🎉 init:项目初始化 |
分支推送gitlab频次
开发阶段，feature每日推送，develop每周至少一次推送，现场部署前必须有对应的release分支，以及部署完成后更新readme文档合并进main分支。readme文档包括版本部署地以及其他信息。
质量要求
能用CI/CD的都使用，要求develop分支的推送每周至少有一次能通过。
项目成员要求
除主要开发人员外，每个项目都需要把观察员拉进项目，观察员要有可查看的权限，用来监督项目分支提交情况。
这篇笔记整理自我自己的实践记录，如果做法有出入，或者你踩过别的坑，欢迎到留言板一起聊聊。
