Git_014:最佳敏捷分支策略

目前业界有三种分支策略:Git Flow,Github Flow,Gitlab Flow,它们都是采用"功能驱动式开发"(Feature-driven development,FDD)。所谓 FDD,指的是需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(bugfix 或 hotfix branch)。完成开发后,该分支就合并到主分支,然后该分支被删除。

在分析了三种分支策略后,笔者发现三种策略都有某些缺陷,不能完全满足敏捷开发、持续集成、持续部署的要求。

为此,笔者提出最佳敏捷分支策略。


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
2.1  feature 分支
feature 分支是功能分支,用于开发各个功能模块,格式型如 feature/。
开发人员领取各个功能任务后, 从 master 分支创建各自的 feature 分支,通过单元测试和集成测试(由开发人员测试)后,最终合并到 master 分支
所有 feature 分支都合并到 master 分支后,创建系统测试环境,由测试人员进行系统测试;创建验收测试环境,由业务人员进行验收测试。

2.2. bugfix 分支
bugfix 分支是补丁分支,用于修复在测试环境中测试出来的各个 bug,格式型如 bugfix/。
在测试环境中测试出来的 bug,由开发人员领取任务, 从 master 分支创建各自的 bugfix 分支进行修复,开发人员需要为每个 bugfix 单独编写单元测试和集成测试,测试通过后,最终合并到 master 分支

2.3. hotfix 分支
hotfix 分支是热补丁分支,用于修复在生产环境中发现的各个 bug,格式型如 hotfix/。
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/

你可能感兴趣的:(Git)