代码分支策略选择

代码分支策略选择

主流方案

主干开发(TBD)

开发者在一个master分支中对代码进行协作，除了发布分支外没有其他开发分支

每次集成冲突少效率高

能享受持续交付带来的所有好处

无需在分支之间做切换

容易出现“一粒老鼠屎坏了一锅粥”的灾难

要借助特性切换等机制保证线上运行的正确性，这会引入新的问题

特性分支开发

Git Flow

分为Master、Hottfix、Release、Develop、Feature 5个分支

完善的发布流程

流程太繁琐，需要维护很多分支

GitHub Flow

master 分支时常保持可以部署的状态

新的作业时要从master 创建新的分支

代码完成后通过GitHub提交pull request；通过自动化测试和代码审查后，合并到master分支。再从master部署到生产环境

以部署为中心的开发模式，通过简单的功能和规则，持续且高速和安全地进行部署

依赖GitHub和公司的部署流程

GitLab Flow

带生产分支

无法控制准确的发布时间，但又要求不停集成

需要创建一个production分支来放置发布的代码

带环境分支

要求所有代码都在逐个环境中测试通过

需要为不同的环境建立不同的分支

带发布分支

用户对外界发布软件的项目，同时需要维护多个发布版本

尽可能晚的从master拉取发布分支

Bug的修改应先合并到master，然后cherry pick到release分支

分支选择策略

主干开发

开发团队系统设计和开发能力强有一套有效的特性切换实施机制，保证上线后无需修改代码就能修改系统行为需要快速迭代，想获得CI/CD所有好处

不具备主干开发能力有预定的发布周期需要执行严格的发布流程

不具备主干开发能力随时集成随时发布分支集成后经过代码评审和自动化测试，就可以立即发布应用

GitLab Flow(带生产分支)

不具备主干开发能力无法控制准确的发布时间，但又要求不停集成

GitLab Flow(带环境分支)

不具备主干开发能力需要逐个通过各个测试环境验证

GitLab Flow(带发布分支)

不具备主干开发能力需要对外发布和维护不同版本