代码分支策略选择
2021-10-26 21:50:14 1 举报AI智能生成
代码git分支策略选择
作者其他创作
大纲/内容
主流方案
主干开发(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所有好处
Git Flow
- 不具备主干开发能力
- 有预定的发布周期
- 需要执行严格的发布流程
GitHub Flow
- 不具备主干开发能力
- 随时集成随时发布
- 分支集成后经过代码评审和自动化测试，就可以立即发布应用
GitLab Flow(带生产分支)
- 不具备主干开发能力
- 无法控制准确的发布时间，但又要求不停集成
GitLab Flow(带环境分支)
- 不具备主干开发能力
- 需要逐个通过各个测试环境验证
GitLab Flow(带发布分支)
- 不具备主干开发能力
- 需要对外发布和维护不同版本
0 条评论
下一页
