GitHub Flow 起源于 GitHub 的内部开发实践，旨在提供一种更加灵活、简单的方法来适应现代软件开发的快速迭代需求。它强调简单性和快速迭代，只需一个常驻的主分支（main 或 master），所有的功能开发、修复和改进都在从主分支派生的短暂功能分支上进行，因为其简单清晰的特点，一经推出就迅速的被大量的开源社区项目所采用。
分支定义
-
主分支 (main 或 master)
-
功能：存放可发布、部署的稳定版本代码。
-
生命周期：常驻。
-
质量：高质量标准，全面测试、部署成功后才能合入。
-
-
支持分支 (feature/ + 描述性名称)
-
功能：用于开发新特性、作业或修复bug。
-
生命周期：临时，自master拉出，合并到master后删除。
-
质量：充分测试，严格代码交叉评审（MR），部署验证（需求/任务追溯）。
-
GitHub 分支的主要概念和特点
-
主分支（main或master）：主分支是GitHub项目的默认分支，通常用于存放稳定版本的代码。新的特性和修复通常不会直接在主分支上开发，以确保主分支的稳定性。
-
特性分支（Feature branches）：特性分支用于开发单个功能或解决问题、试验探索等。开发人员可以从主分支分支出来，然后在特性分支上进行工作。一旦特性完成，可以通过拉取请求（Pull Request）将其合并回主分支或其他指定分支。
-
分支保护规则（Branch protection rules）：GitHub允许项目管理员设置分支保护规则，以确保分支的稳定性和质量。这些规则可以包括要求代码审查、通过CI/CD测试等。
-
拉取请求（Pull Requests）：拉取请求是GitHub上的一种功能，用于将特性分支的更改合并回主分支或其他目标分支。拉取请求允许团队进行讨论、审查和测试，以确保更改不会引入问题。
-
发布分支（Release branches）：类似于Git Flow中的发布分支，GitHub项目可以创建发布分支，用于准备新版本的发布。发布分支上进行最后的测试、修复缺陷和文档更新，并在准备好时合并回主分支。
-
保护分支（Protected branches）：GitHub允许项目管理员将某些分支标记为“受保护的”，以防止非授权用户直接向其推送代码。这有助于确保关键分支的安全性和稳定性。
-
协作与权限控制：GitHub提供了灵活的协作和权限控制机制，可以定义哪些团队成员可以访问、编辑和合并分支。这有助于维护代码库的安全性和可维护性。
流程模型
功能交付
1. 新功能规划：
- 确定新功能的需求或问题，并创建相应的特性分支（例如 feature/new-feature）。
- 分支规划时可以考虑面向下一个release以及未来的release来建立分支。
2. 开发和自测：
- 在特性分支上进行开发工作，期间不断提交代码更改。
-
开发者在本地或者开发环境中进行自测。
3. 创建PR：
-
完成开发后，通过创建 Pull Request (PR) 向 master 分支发起合并请求。
-
PR 触发自动化测试（单元测试、集成测试等）。
4. 解决代码审查评论中的问题：
-
PR之后会进行严格的代码评审（相对于目前企业中的代码评审时间要更长，讨论也会更充分）。
5. 部署验证：
-
在预发布环境（如准生产环境）进行金丝雀部署或蓝绿部署，对新功能进行验证。
-
可能包括生产数据回放测试，以验证新功能在实际数据条件下的性能和稳定性。
6. 合并分支：
-
一旦通过所有测试和验证，PR 被审查并合并到 master 分支。
-
合并后会触发生产环境的部署。
分支管理
如上图是 GitHub Flow 流程下的分支管理模型，在不引入其余类型分账制的情况下，该分支模型管理流程相对简单，与前面的功能交付流程基本一致，这里不再重复说明了。
非阻塞式集成
GitHub flow 最大的特点在于部署（Deploy）发生在合并（Merge）之前，这就是 GitHub flow 的核心，非阻塞式集成 —— 在产生任何副作用之前得知当前修改的所有集成效果，达到真正的持续集成。
适用场景
GitHub Flow适用于多种开发场景，尤其是以下情况：
-
快速迭代项目：对于需要频繁更新和快速响应市场变化的项目，GitHub Flow 提供了一种高效的管理方式。
-
小到中型团队：其简化的流程适合小到中型的开发团队，可以快速上手和实施。
-
持续部署环境：对于采用持续部署实践的项目，GitHub Flow 支持快速、自动化地将更改部署到生产环境。
-
开放源代码和协作项目：简单的分支模型和强调代码审查的流程促进了开源社区和跨团队的协作。
524
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
