一个关于 GIT 提交的疑问？

[milukun]

目前一个项目，线上是有 dev 、uat 、prd 三个分支，本期版本开始后，三个分支代码基本是一样的，只是里面可能部分标记环境的变量不同


（ 1 ）要求开发时在自己的分支上开发，例如需求 120 即 feature/120 分支
（ 2 ）同时要求不允许 dev 合并到 uat 再合并到 prd 这样合上去，而是单独提交。即 feature/120 开发完成，push 后，提交 MR 到 dev ，dev 测试没问题，再提交到 uat...以此类推

问：怎么操作最方便？
目前是 1️⃣ 从远程 dev new 一个分支 feature/120 开发完成，push 后，提交 MR 到 dev ，自动删除 feature/120
2️⃣ 然后我要重新从远程 uat new 一个分支 feature/120 ，再次把改动的代码贴过来，push 后，提交 MR 到 uat ，自动删除 feature/120
3️⃣ 然后然后我要从远程 prd new 一个分支 feature/120 ，再次把改动的代码贴过来，push 后，提交 MR 到 prd ，
自动删除 feature/120

也就是我至少要“重新开发”两次（其实是复制新增的代码过去，这个过程我觉得很不合理，但是又没有想到更好的办法？

* 注意，我没有办法保留 dev 开发的 feature/120 直接提交到 uat 上，因为 dev 和 uat 的代码不是完全相同的，非常蛋疼的在里面有写死的 api-url 和 环境变量

[ztxcccc]

dev 和 uat 代码不一样，那每个环境做的集成测试不是白做了？

[zjp]

流程就不合理很难说有什么好的操作办法…
在没有功能开发进行中时，三个分支的代码应该是一样的。环境变量用构建工具/配置中心管理
第三步到合并 prd 应该是自动化的，手工合代码不能保证最终 prod 的代码和 uat 一致，这样测试有没有意义很值得怀疑

[Ljxtt]

后面的不直接 cherry pick 吗？还是说连改动的代码都不一样？

[milukun]

@Ljxtt 之前完全没有过这样的场景😢 我去学习一下 cherry pick

[milukun]

@Ljxtt 实际情况比题目中的复杂度 double 一下，因为项目有两个线上版本（需求不同，显示内容不同之类的），因此有 6 个分支
dev 、uat 、prd
dev-r 、uat-r ，prd-r
也就是上面的操作其实我要做 6 次😅

[ztxcccc]

@milukun 你不同分支代码不一样/不是 merge 上去的话，不一定能用 cherry-pick

[milukun]

@ztxcccc #6 dev 、uat 、prd 这三个分支上，我自己的改动是完全一样的，只是三个分支本身其他代码会有区别

[tianmalj0613]

环境变量,url 什么的，直接放代码里面？
和环境有关的东西应该放在部署里面，你们这个和代码耦合很明显不合理啊

[cnoder]

dev 、uat 、prd 应该是一个分支

[admol]

步骤 1 、2 后不要自动删除 feature 分支，第 3 步完成后再删除。
分支合到 dev 和 uat 后不会再回来修改 feature 分支上的 BUG ，为什么要马上删除？

[leonshaw]

rebase --onto

[Katrol]

@milukun 自己改动一样 那就 cherry pick 过去，有冲突再解决

[dzdh]

prd 主干
dev 开发

开发都是从 prd 切 feature 分支，合并到 dev ，dev 测试没问题，feature 合到 prd 。

环境变量参考 laravel/flask env 。项目代码从 configrepository 获取配置，configrepository 从 env 读取

[ztxcccc]

@milukun #7 和是不是你的没有关系，主要是你控制不了别人，这才需要一级一级的 PR

[Habyss]

总有一个稳定的基本线上分支吧 比如 prd
前提:
1. dev 也是从 prd new 出来的, 直接在 dev 分支修改 [可能部分标记环境的变量不同], 并 push
2. uat 也是从 prd new 出来的, 直接在 uat 分支修改 [可能部分标记环境的变量不同], 并 push
开发:
1. 从 prd new 新分支 feat-120, 开发, merge 到 dev, 发布联调测试之类的
2. 上一步 ok 之后, 直接把 feat-120 merge 到 uat, 发布测试验证之类的
3. 上一步 ok 之后, 直接把 feat-120 merge 到 prd, 发布

工作这么久, 一直都是这样开发的..从稳定上线的分支 new 新分支, 只改动自己功能分支的东西, 然后 merge 到其他 dev,test,prd 分支

[milukun]

@admol 因为 dev 合并完，我要推基于 uat 的 feature/120 分支上去呀（分支名相同），前提是 dev 和 uat 代码不一致，所以没办法直接一个 feature/120 合并三次，如果可以就没有这个题目了

[shaozelin030405]

dev 和 uat 的代码 merge 一下，conflict 处理一下。哪天 dev 和 uat 的行为不一致有够你们受的。

[devopsdogdog]

因为 dev 和 uat 的代码不是完全相同的，非常蛋疼的在里面有写死的 api-url 和 环境变量

有这些骚操作的，git 流程有问题不奇怪，

应该是 dev new 个新分支。 合并到 dev ,然后 dev 合并到 uat 。uat 直接合并 prd 吧

感觉没有基线。 你独立推送，感觉像是使用 svn ...

[unco020511]

环境应该都基于一份相同的代码,然后用其他工具在部署打包的时候来区分环境

[thevita]

cherry-pick

歪楼:

“三个分支代码基本是一样的，只是里面可能部分标记环境的变量不同“
这种情况应该首选通过 flag 来实现

手动处理最大的问题是: 一段时间之后，就没人知道这三个分支 除了 “部分标记环境的变量不同” 外是不是真的完全一样了

再次的选择:
引入一些 自动化的工作流, 如: merge 到 dev 的 feature 合并后，自动创建 到 uat, prd 的 mr