更新时间：2023-05-06 GMT+08:00
Git flow工作流
Gitflow一般用于管理大型项目，它为不同的分支分配一个很明确的工作角色，并定义分支之间什么时候进行交互，如Gitflow工作流如下图所示。
工作方式
- master分支：
生产分支，最稳定的版本，一直是ready to deploy状态。不接受开发人员直接commit，只接受从其他分支merge操作。在很多企业中，这个分支被默认开启分支保护，只有维护者可以操作。
- hotfix分支：
从master分支拉取的临时修复分支，用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号，这个修改也需要同时合入develop分支。
- develop分支：
从master分支拉取的开发分支，用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。
- release分支：
临近既定的发布日，就从develop分支上拉取一个release分支，任何不在当前分支中的新功能都推到下个发布中。release分支用于发布，所以从当前时间点之后新的功能不能再加到这个分支上，这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了，release分支合并到master分支并分配一个版本号打好Tag；另外，这些从release分支新做的修改要反向合并回develop分支。
- feature分支：
开发者使用的特性分支，父分支是develop分支，当新功能完成时，合入develop分支。新功能提交从不直接与master分支交互。
开发人员提交新功能的两种途径：
- 团队有专人review审核新功能
- 开发人员自审核新功能
- 开发人员在本地仓库将feature分支合并到develop分支，并删除feature分支。
- 将本地develop分支的修改推送到代码托管平台（中央仓库）。
优点
- 使用一个用于发布准备的专门分支（release分支），使得一个团队可以在完善当前的发布版本的同时，可以在develop分支并行继续开发下个版本的功能。这也打造了可视化的发布阶段，团队成员都可以在仓库网状结构中可以看到发布状态。
- 使用紧急修复分支（hotfix分支）让团队可以处理紧急问题的同时而不打断其它工作或是等待下一个发布再合入hotfix修改。可以把hotfix分支想成是一个直接在master分支上处理的临时发布。
- 大型项目人员协作频繁，流程较多，合理的多角色分支帮助研发有条不紊进行。
- 更符合devops理念。
缺点
- 学习成本较高。
- 如果团队不遵守使用约定，带来的影响更大。
父主题： Git工作流
