这是一个创建于 1085 天前的主题，其中的信息可能已经有所发展或是发生改变。
这里想做个小调查 在你们的 CI CD 管道中 你们使用哪种方式管理分支呢？
- master dev ，开发 snapshot 在 dev 分支 或者从其他分支合并到 dev 最终从 master 发布 release 版本 - 只有一个分支 main ｜ master 所有开发在新建临时分支上，完成后做个 MR 请求 ，test 和 codereview 通过后合并到 main 分支 并且最终从 main 分支发布 release - 同上面这个 不过最终发布从 release 分支发布 主分支保持 snapshot 版本 - 不同大版本程序各自占有一个独立分支， 然后根据需求创建新分支， 最终从大版本分支上做 release 第 1 条附言 2023-01-16 05:50:16 +08:00
发现了掘金上的一篇文章讲了关于 git flow 问题
https://juejin.cn/post/6989145079667490847#heading-6
大部分的项目使用 dev 和 master 双分支其实是没有意义的，很多时候新的程序开发玩 merge request 到 main / master 上就好了，直接在 main 分支上做新版本发布更新就好了 tag 用来指向 release 版本
https://juejin.cn/post/6989145079667490847#heading-6
大部分的项目使用 dev 和 master 双分支其实是没有意义的，很多时候新的程序开发玩 merge request 到 main / master 上就好了，直接在 main 分支上做新版本发布更新就好了 tag 用来指向 release 版本
 | 1 mulu 2023-01-09 23:21:25 +08:00 via Android 3 |
 | 2 IvanLi127 2023-01-09 23:48:04 +08:00 via Android 喜欢 2 |
 | 3 perfectlife 2023-01-10 08:05:24 +08:00 via Android 你还要考虑一下你们有几个环境吧 |
 | 4 acthtml 2023-01-10 09:09:07 +08:00 |
 | 5 zh6335901 2023-01-10 09:28:09 +08:00 2 |
 | 6 yaroga 2023-01-10 09:37:06 +08:00 3 |
 | 7 zhongchaowade 2023-01-10 10:19:31 +08:00 2 |
 | 8 sujin190 2023-01-10 10:54:16 +08:00 如果是 CI CD 后端微服务的话其实感觉都不好，在这个流程中，GIT 的分支管理应该满足三个不同需求 开发-》不同人不同功能分别在不同分支开发 codereview 后合并进总 dev 分支 测试-》按不同测试提测进度合并到 test 分支然后构建测试服务自动完成部署更新 发布-》测试完成合并进 master 构建发布版最少上线同时创建 tag ，这个过程可能又有多个不同功能分别开发测试最后一起发布 微服务 devops 流程中 GIT 分支不应该只管理开发过程，测试发布依然用镜像版本号来管理提测和发布进度，感觉过于坑了，因为镜像不能直接 diff 出改了啥，配合 CI CD 后应该随时提测更新发布，一天一个项目更新个十几或者几十次很容易就乱七八糟了完全分不清哪个改动是哪个版本的，所以镜像版本实操性太弱，应该还是以代码来做版本管理，然后在 build 的镜像信息里打入 git 的 commit 信息，然后同时记录到链路追踪日志里，整个就比较清楚了，CI CD 的执行也会比较顺畅 当然以上流程需求其实实际操作上是大多简化运行的，毕竟迭代虽然很多但是微服务体系下单个项目同时被修改的概率还是低很多的，所以大多数情况下只一个人改一个功能应该就 dev test 和 master 三个分支就行吧 |
 | 9 Nnq OP @perfectlife 可能与部署方式有关 与环境可能没多大关系 |
| 11 Nnq OP @sujin190 谢谢分享 你们的 test 分支是从 dev 分支衍生出来的？ build commit 信息这块基本上就是为了追溯。 你描述的这个情况也就是说有可能最后 master 分支只包含 test 过了的 test 分支 code ？ |
| 12 perfectlife 2023-01-12 09:50:19 +08:00 via Android @Nnq 我们的是提交到 dev/test/uat 分支的代码会自动构建并发并发布到 dev/test/uat 环境，生产环境的依赖 tag |
| 13 sujin190 2023-01-12 09:58:18 +08:00 @Nnq #11 dev 和 test 分支其实还有个用途是，dev 是开发分支所以应该自动更新部署到开发患教，test 则应该自动部署到测试环境，master 是最终版肯定是只包含可发布的代码才对，所以一般都是测试完成从 test 分支合并过去的 微服务 devops 还有个麻烦的事情就是，假如同时有个功能版本同时开发，那就需要部署多个不同版本，服务非常多那这个工作量就非常大了而且非常耗资源，所以我们的做法是标准的 dev 和 test 分支其实是基础版本，一般不能直接用于开发测试，而是每个版本再次创建 dev-v1 和 test-v1 这样的版本分支，然后在通过 CI CD 自动部署到 k8s 集群里，这个过程只有你当前版本需要改动的项目才建版本分支部署项目，然后通过流量染色和服务网格来组一个完整服务切面，这样就能用很小的资源和工作量给每个版本一个相对独立和完整的环境了 通过流量染色和服务网格来组一个完整服务切面这个过程也不复杂，就是前端请求里应该都带标准的版本、设备、用户标识信息，这些信息到后端后会在整个请求链路中传递，然后通过服务网格的流程来做流量匹配，如果某个服务有对应版本就请求对应版本的服务，没有则由基础版本来处理，这样你只要部署你需要修改的项目，然后用当前版本的 app 访问就能访问到你修改的服务上去，无论你的服务位于请求链路的前面和后面，而创建 dev-v1 和 test-v1 分支部署到 k8s 并注册服务网格信息这个过程完全由 CI CD 自动完成 比如整个微服务由 200 个服务组成，现在有一个版本 v1 的迭代只需要修改项目 A 和 B ，那么你只需要在项目 A 和 B 创建 dev-v1 分支，这样你就有了一个独立的 v1 版本的开发环境，其余的项目无需任何处理，测试环境也是一样的 这样一个 v1 版本的整个开发测试发布过程就变成了 dev-v1 分支完成开发，然后基于 dev-v1 创建 test-v1 提测，测试完成等到发布周期是合并进 master 统一发布，发布后 master 再合并到 dev 和 test 分支完成基础版本更新，最好删除 dev-v1 和 test-v1 分支清理环境和资源 |
Select Language