Git Flow 是 Vincent Driessen 在博客 A successful Git branching model � nvie.com
中提出来的。
Vincent Driessen
分支模型类似这样：
git flow
主要分支包括：
master：主分支，包含生产代码。develop：开发分支，所有功能和错误修复在升级到主分支之前都会合并。feature：为开发各个功能而创建的临时分支，当功能完成时，这些临时分支会合并回分支。release：为准备下一个版本而创建的分支，允许在与合并之前进行错误修复和最终调整master。hotfix：为修复生产代码中的关键错误而创建的分支，这些分支直接合并到master和中develop。使用git flow 日常操作步骤：
创建新功能开发的Feature分支在feature分支上进行代码改动，提交一旦在feature分支上完成新功能的开发，将其合并回develop分支当develop分支准备发布时，从develop分支创建一个release分支当release分支完成版本的微调和Bug修复，release分支需要合并到master和develop如果在master分支代码中发现了重要的bug需要立即修复并发布，需要从master分支创建一个hotfix分支，在这个分支上进行问题修复修复完毕并测试无误后，将改动合并回master和develop分支，并创建一个发布标签。下面利用 Git Flow 工具来完成 在git flow 中分支管理的关键步骤
# 从develop分支创建一个名为# feature/FEATHRE_NAME 的新分支 git flow feature start FEATHRE_NAME# 完成 feature/FEATHRE_NAME 分支功能开发，# 并合并到develop分支git flow feature finish FEATHRE_NAME# 从develop分支创建一个release/1.0.0 分支git flow release start 1.0.0# 功能修复和测试完成后# 将release分支需要合并到master和develop分支 git flow release finish 1.0.0# 从master分支创建Hotfix分支 git flow hotfix start 1.0.0# 完成Hotfix分支# 将Hotfix分支合并到master和develop分支# 并创建发布标签git flow hotfix finish 1.0.0
二、GitHub flow
GitHub Flow 是 Scott Chacon
Scott Chacon
提出的一个简单、轻量级的工作流程，是一个用于团队合作开发的简单而有效的 Git 工作流程，强调的是流畅和简洁的工作流程。这个工作流程只有一条生产用的主分支（通常称为 "master" 或 "main"），所有的新功能、bug 修复等都是在这条主分支上创建的新分支。
下面是使用 Github Flow 的基本步骤：
从 Master/Main 分支创建新分支当准备开始一个新的工作项（无论是新的功能、修复 bug、还是其他改动）时，应该从 master/main 分支创建一个新分支。
git checkout master # or main git pull git checkout -b my-new-feature在新分支中添加 Commit
在新分支中进行工作，并且提交更改。
git add . git commit -m "My new feature"在远程仓库上发布新分支
这一步将本地的新分支推送到远程仓库上
git push -u origin my-new-feature向 Master/Main 分支提交 Pull Request
当新功能准备好并入 master/main 分支时，可以在远程仓库上创建一个 Pull Request，可以对其进行代码审查。
Pull Request 的 Review 和合并审查代码，审查通过后就可以将新分支合并到 master/main 分支。在远程仓库上可以选择 "Merge Pull Request" 按钮执行此操作。
部署一旦代码被合并到 master/main 分支，就应该准备将这部分代码部署到生产环境。
在Github Flow 工作流程中应保证master/main 分支的代码始终处于可部署的状态。
这个流程极其简单，并且高度注重持续部署和持续集成流程。使用这个流程，部署过程应该是自动化的，只要新代码被合并到 master/main 分支，就可以自动部署。
三、GitLab flow
GitLab Flow 是一种灵活的工作流程模式，设计来适应各种从简单到复杂的开发项目。它是对 Git flow 和 Github flow 进行的一种改进和扩展，并在此基础上加入了环境分支的概念，其主要是适应连续交付（Continuous Delivery）和部署（Continuous Deployment）的需要。
可以简单的把GitLab flow 看成下面这样子：
GitLab Flow = Feature Branch 工作流程 + 环境分支GitLab Flow 的核心包含以下几个方面：
主分支保持稳定（Main branch always stable）：主分支（通常叫做 main 或 master）是永远保持稳定的。所有成品都是从这个分支中发布的。功能分支（Feature branches）：类似于 GitHub Flow，在功能分支上进行新功能的开发。完成后通过 Merge Request（MR）合并回主分支。环境分支（Environment branches）：用于部署到不同的环境（例如：生产、预生产）。这与Git Flow中的develop、release分支有些相似，但提供更大的灵活性和明确性。利用标签（Tags）进行发布：使用标签来标识生产环境中的发布版本。下面是 GitLab Flow的流程图：
GitLab Flow 工作流
在Gitlab flow 中一般把 主分支（main或master）、环境分支设置为受保护的，不允许开发进行提交。在使用 Gitlab flow 时应遵守 上游优先 的基本原则，即：只存在一个主分支master，此分支是所有其他分支的上游。
比如上图中，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。代码的变化，必须由”上游”向”下游”发展：
master --merge--> pre-production --merge--> production使用 Gitlab flow 的一般步骤为：
从主分支（main或master）创建feature功能分支feature 功能分支开发完成后，发起合并到main的MR请求代码审核通过后，合并feature 功能分支到主分支（main或master）主分支（main或master）一般会集成持续集成和持续部署合并到主分支（main或master）测试通过后，合并到环境分支一般为生产分支（如果有预生产分支，先合并到预生产分支，然后再从预生产分支合并到生产分支）最后在生产环境分支上发布标签选择正确的 Git 工作流程Git flow 、Github flow、Gitlab flow 三个工作流中都是基于敏捷软件开发方法中的特性驱动开发（Feature-Driven Development，简称FDD），都是从主分支（比如main或master）创建一个新的特性分支，在特性分支上进行特性的具体开发工作，包括编码、单元测试等。在结合特性驱动开发（FDD）的情况下，Git flow最复杂，Github flow 最简单、Gitlab flow最灵活。
每种流程都有其优点和局限性，选择正确的 Git 工作流程要考虑团队规模、项目特性、协作方式以及发布频率等情况来决定。没有一种单一的“正确”工作流程适合所有项目。在特性驱动开发（FDD）的场景下，以下是一些一般准则，可结合实际情况选择最合适的工作流程：
对于多版本维护和周期性发布：如果项目需要同时维护多个版本，并有较为固定的版本发布周期，Git Flow可能更适合。对于快速迭代和持续部署：如果项目追求的是快速迭代和持续部署（敏捷开发），GitHub Flow非常适合对于需要灵活性和稳定性：如果你的项目需要在不同的部署环境（如开发、测试、预生产和生产环境）之间可靠地（每次都是经过测试验证的）传输代码，同时又想要保留一定的部署灵活性（即可以根据需要选择何时以及如何将变更部署到不同环境），GitLab Flow可能是最佳选择。
