git-flow

Git Flow 最开始是由 Vincent Driessen 发行并广受欢迎，这个模型是在 2010 年构思出来的，而现在距今已有 10 多年了，而 Git 本身才诞生不久。在过去的十年中，Git Flow 在许多软件团队中非常流行

分支命名规范:

master 分支：master 分支只有一个，名称即为 master 。GitHub 现在叫 main

develop 分支：develop 分支只有一个，名称即为 develop

feature 分支：feature/<功能名>，例如：feature/login，以便其他人可以看到你的工作

hotfix 分支：hotfix/日期，例如：hotfix/0104
1234567

分支说明

master || main 分支
- 存储正式发布的产品，master || main 分支上的产品要求随时处于可部署状态。master || main 分支只能通过与其他分支合并来更新内容，禁止直接在 master || main 分支进行修改。
develop 分支
- 汇总开发者完成的工作成果，develop 分支上的产品可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品。develop 分支只能通过与其他分支合并来更新内容，禁止直接在 develop 分支进行修改。
feature 分支
- 当要开发新功能时，从 master 分支创建一个新的 feature 分支，并在 feature 分支上进行开发。开发完成后，需要将该 feature 分支合并到 develop 分支，最后删除该 feature 分支。
release 分支
- 当 develop 分支上的项目准备发布时，从 develop 分支上创建一个新的 release 分支，新建的 release 分支只能进行质量测试、bug 修复、文档生成等面向发布的任务，不能再添加功能。这一系列发布任务完成后，需要将 release 分支合并到 master 分支上，并根据版本号为 master 分支添加 tag，然后将 release 分支创建以来的修改合并回 develop 分支，最后删除 release 分支。
hotfix 分支
- 当 master 分支中的产品出现需要立即修复的 bug 时，从 master 分支上创建一个新的 hotfix 分支，并在 hotfix 分支上进行 BUG 修复。修复完成后，需要将 hotfix 分支合并到 master 分支和 develop 分支，并为 master 分支添加新的版本号 tag，最后删除 hotfix 分支。

提交信息规范

提交信息应该描述“做了什么”和“这么做的原因”，必要时还可以加上“造成的影响”，主要由 3 个部分组成：Header、Body 和 Footer。

Header Header 部分只有 1 行，格式为<type>(<scope>): <subject>。

type 用于说明提交的类型，共有 8 个候选值：

feat：新功能（ feature ）
fix：问题修复
docs：文档
style：调整格式（不影响代码运行）
refactor：重构
test：增加测试
chore：构建过程或辅助工具的变动
revert：撤销以前的提交
scope 用于说明提交的影响范围，内容根据具体项目而定。
subject 用于概括提交内容。

Body 省略

Footer 省略

Git—Flow的基本原则是需要什么分支就给什么分支，任何事都有很明确的分支。比如说要集成，就有develop分支，要开发就有feature分支，要发布有release分支，每个都是不同的分支。每种类型的分支都有确定的用途。

比如说feature分支，是很多个feature并行开发的时候用来去做工作隔离，避免彼此之间有冲突。而release分支是用来做发布的隔离，使得发布之间不会有冲突。

我们发现这种模式很好地做了隔离，但是在信息同步的过程中，它需要基于develop频繁地集成去做同步，并且在各个分支中间做相应的cherry-pick 或者是rebase这样的方式来做的。

这个时候，我们就会发现分支太多，而且一个commit从feature开发到最终发布要经历好几个分支，其中分支的流转和merge规则非常麻烦。

所以Git—Flow也不是仙丹，过多的分支增加了分支管理的复杂度。还有如果Feature分支的生命周期特别长，它的合并耗时也会变得很长。而且Develop分支和Master分支同时存在，好像Develop分支的意义不是特别大。另外区分Feature分支和hotfix好像意义也不是特别大。

所以Git—Flow虽然增加了很多的分支，让各种工作尽可能地隔离开来，但是它信息同步是很麻烦的，而且它管理这些分支的难度也特别大。