目前业界有三种分支策略：Git Flow，Github Flow，Gitlab Flow，它们都是采用"功能驱动式开发"（Feature-driven development，FDD）。所谓 FDD，指的是需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（bugfix 或 hotfix branch）。完成开发后，该分支就合并到主分支，然后该分支被删除。
在分析了三种分支策略后，笔者发现三种策略都有某些缺陷，不能完全满足敏捷开发、持续集成、持续部署的要求。
为此，笔者提出最佳敏捷分支策略。
1. 主分支
代码库有两个主分支作为常设分支。
1.1 master 分支
master 分支用于日常开发，存放最新的代码。
master 分支对应测试环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
release 分支用于跟踪线上版本，存放所有对外正式发行的版本。
release 分支对应生产环境。
所有测试通过后，从 master 分支创建 release 分支，格式型如 release/1.0，同时在该 release 分支上打 Tag，格式型如: 1.0，注意前面不要加 v，v1.0 不符合习惯。
如何保护 release 分支❓
2. 临时分支
feature 分支是功能分支，用于开发各个功能模块，格式型如 feature/request-number。
开发人员领取各个功能任务后，从 master 分支创建各自的 feature 分支，通过单元测试和集成测试（由开发人员测试）后，最终合并到 master 分支。
所有 feature 分支都合并到 master 分支后，创建系统测试环境，由测试人员进行系统测试；创建验收测试环境，由业务人员进行验收测试。
2.2. bugfix 分支
bugfix 分支是补丁分支，用于修复在测试环境中测试出来的各个 bug，格式型如 bugfix/bug-number。
在测试环境中测试出来的 bug，由开发人员领取任务，从 master 分支创建各自的 bugfix 分支进行修复，开发人员需要为每个 bugfix 单独编写单元测试和集成测试，测试通过后，最终合并到 master 分支。
2.3. hotfix 分支
hotfix 分支是热补丁分支，用于修复在生产环境中发现的各个 bug，格式型如 hotfix/bug-number。
hotfix 分支对应准生产环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
在生产环境中发现的 bug，由开发人员领取任务，从当前发现问题的 release 分支创建各自的 hotfix 分支进行修复，开发人员需要为每个 hotfix 单独编写单元测试和集成测试，
所有测试通过后，将 hotfix 分支合并到 master 分支，然后创建 release 分支，格式型如 release/1.0.x，同时在该 release 分支上打 Tag，格式型如: 1.0.x，注意前面不要加 v，v1.0 不符合习惯。
参考文献：
1. https://gist.github.com/digitaljhelms/4287848
2. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
3. https://www.cnblogs.com/doit8791/p/10147321.html
4. https://blog.csdn.net/hu_zhiting/article/details/95030586
5. http://www.ruanyifeng.com/blog/2012/07/git.html
6. https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
7. https://mohamedradwan.com/2018/01/08/promoting-your-application-deployment-to-different-environments-from-branches-with-and-without-feature-toggle/
在分析了三种分支策略后，笔者发现三种策略都有某些缺陷，不能完全满足敏捷开发、持续集成、持续部署的要求。
为此，笔者提出最佳敏捷分支策略。
1. 主分支
代码库有两个主分支作为常设分支。
- master
- release
1.1 master 分支
master 分支用于日常开发，存放最新的代码。
master 分支对应测试环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
如何保护 master 分支❓
1.2 release 分支release 分支用于跟踪线上版本，存放所有对外正式发行的版本。
release 分支对应生产环境。
所有测试通过后，从 master 分支创建 release 分支，格式型如 release/1.0，同时在该 release 分支上打 Tag，格式型如: 1.0，注意前面不要加 v，v1.0 不符合习惯。
如何保护 release 分支❓
2. 临时分支
- feature
- bugfix
- hotfix
feature 分支是功能分支，用于开发各个功能模块，格式型如 feature/request-number
开发人员领取各个功能任务后，从 master 分支创建各自的 feature 分支，通过单元测试和集成测试（由开发人员测试）后，最终合并到 master 分支。
所有 feature 分支都合并到 master 分支后，创建系统测试环境，由测试人员进行系统测试；创建验收测试环境，由业务人员进行验收测试。
2.2. bugfix 分支
bugfix 分支是补丁分支，用于修复在测试环境中测试出来的各个 bug，格式型如 bugfix/bug-number
在测试环境中测试出来的 bug，由开发人员领取任务，从 master 分支创建各自的 bugfix 分支进行修复，开发人员需要为每个 bugfix 单独编写单元测试和集成测试，测试通过后，最终合并到 master 分支。
2.3. hotfix 分支
hotfix 分支是热补丁分支，用于修复在生产环境中发现的各个 bug，格式型如 hotfix/bug-number
hotfix 分支对应准生产环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
在生产环境中发现的 bug，由开发人员领取任务，从当前发现问题的 release 分支创建各自的 hotfix 分支进行修复，开发人员需要为每个 hotfix 单独编写单元测试和集成测试，
所有测试通过后，将 hotfix 分支合并到 master 分支，然后创建 release 分支，格式型如 release/1.0.x，同时在该 release 分支上打 Tag，格式型如: 1.0.x，注意前面不要加 v，v1.0 不符合习惯。
参考文献：
1. https://gist.github.com/digitaljhelms/4287848
2. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
3. https://www.cnblogs.com/doit8791/p/10147321.html
4. https://blog.csdn.net/hu_zhiting/article/details/95030586
5. http://www.ruanyifeng.com/blog/2012/07/git.html
6. https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
7. https://mohamedradwan.com/2018/01/08/promoting-your-application-deployment-to-different-environments-from-branches-with-and-without-feature-toggle/
