1. 引言
Git分支模型的进化史可以追溯到Git诞生的初期，随着开发者们对分布式版本控制的需求不断变化，Git的分支模型也在不断演进。以下是Git分支模型的主要进化历程：
-
单一分支模型 (2005年 - 2007年)： Git最初的版本控制模型是单一分支，即所有的开发工作都在主分支（通常是
master）上进行。这种模型的问题是，当有多个并行开发任务时，开发者们会频繁地覆盖彼此的代码，导致冲突和混乱。 -
多分支模型 (2007年 - 2010年)： 随着Git的发展，人们开始认识到需要更灵活的分支策略来支持并行开发。于是，开发者们开始使用多个分支来隔离不同的开发任务。这种模型下，每个功能或修复都在自己的分支上进行开发，然后再合并到主分支中。
-
Git流模型 (2010年 - 至今)： Git流模型是一种基于多分支模型的扩展，也被称为Git Workflow。它引入了一系列的长期分支和临时分支，以支持持续集成、版本发布等需求。其中，主要的分支包括：
- 主分支（
master或main）： 用于发布稳定版本的分支。 - 开发分支（
develop）： 用于整合各个功能和修复分支的主要分支。 - 功能分支（feature branches）： 用于开发单一功能的分支，从
develop分支创建，完成后合并回develop分支。 - 发布分支（release branches）： 用于准备发布版本的分支，从
develop分支创建，完成后合并回develop和master分支。 - 修复分支（hotfix branches）： 用于紧急修复生产环境中的问题，从
master分支创建，完成后合并回master和develop分支。
Git流模型的优势在于能够清晰地管理各个开发阶段，并支持多人协作和持续集成，有助于减少冲突和错误。
- 主分支（
-
GitHub Flow (2011年 - 至今)： GitHub Flow是GitHub官方提出的一种简化的分支模型，旨在更好地适应持续交付和持续集成。它主要包括以下几个步骤：
- 创建分支：为新功能或修复创建一个分支。
- 提交代码：在分支上进行开发，持续提交代码。
- 发起Pull Request：将分支提交到主分支，发起一个Pull Request（PR）。
- 回顾代码：通过PR进行代码审查，确保代码质量。
- 合并代码：合并到主分支，触发持续集成和自动部署。
GitHub Flow的优势在于简单明了，适用于敏捷开发和快速迭代。
总之，Git分支模型的进化是为了更好地满足不同开发场景下的需求，从最初的单一分支到复杂的Git流模型和简化的GitHub Flow，每一种模型都有其特定的优势和适用范围。开发团队可以根据项目的特点和需求选择适合的分支模型来进行版本控制和协作。
问题：
- 需要有哪些分支？每种分支的角色是什么？
- 在哪个分支发布代码？
- 发布前发现了 bug 怎么解决？
- 发布后发现了 bug 怎么解决？
2. github flow 分支模型
- 令master 分支时常保持可以部署的状态
- 进行新的作业时要从master 分支创建新的分支，新分支名称要具有描述性
- 在2新建的本地仓库分支中进行提交
- 在Github 端仓库创建同名分支，定期push
- 需要帮助、反馈，或者branch已经准备merging时，创建Pull Request，以Pull Request 进行交流
- 让其他开发者进行审查，确认作业完成后与master分支进行合并（合并的代码一定要测试
- 与master分支合并后，立刻部署
适合：框架、库 缺点：每次 bug fix 都需要重新发布
3. git flow 分支模型
4. gitlab flow 分支模型
5. trunk based 模型
其它
- hotfix：有时候 cherrypick 比 merge 更好
