一个关于 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

[wjfz]

1 、从 [prd] 拉一个 feature/120 出来，按你的描述，肯定有很多人往 dev 拉屎，要从 prd 取干净的代码。
2 、开发完成后把 feature/120 合入 dev 测试，如果有 bug ，继续在 feature/120 修复，合入 dev 。
3 、自测完成后把 feature/120 合入 UAT ，有调整继续在 feature/120 分支操作。
4 、提交 mr ，把 feature/120 合入 prd ，完成。

在这个流程中，只要需求不牵扯环境变量的修改，就不用操心环境的事情。

[zoharSoul]

什么奇怪的流程....

[libook]

建议环境变量不放在 Git 项目里。
我们团队几年前做过一次安全治理，环境变量里大多是数据库、中间件之类的连接地址和访问凭据，为了避免隔三差五被人误发到公共 git repo 上去，要求仅负责部署的运维人员可以看到，所以全部信息都从 git 项目里剥离，并重置所有认证信息。这样使用云原生部署的话可以使用配置中心或者 k8s 的 secret 机制来比较方便和安全地管理。

只要不放在 git 项目里，那么几个分支就是可以互相合并的了。而且可以追踪每个 feature 是什么时候、什么人开发、合并到测试分支、合并到生产分支上的。

如果按照你们的使用方式，你可以使用 rebase 将一个 feature 里的所有提交合并成一个提交，再 cherry-pick 到下游分支上，就是这种做法因为没有记录 merge 操作，所以三个分支之间没有联系，你需要自己去比对 commit message ，同时因为使用了 rebase 合并了提交，导致开发过程中的提交历史细节被丢弃。

[Asjun]

我现在也有个项目这样，一些环境变量是在仓库里写死的。分 prod, staging, dev 三个分支。

但我提交的逻辑是，feature -> dev -> staging -> prod ，就单纯的提交 MR 后合并即可。

环境变量部分：
1. 先修改 dev 分支，提交一次；
2. 然后合并到 staging 分支，切换到 staging 分支，再修改成 staging 环境的值，提交；
3. 继续合并到 prod 分支，切换为 prod 分支，再修改成 prod 环境的值，提交。

如果修改的代码里不涉及这些冲突的内容，合并时不会影响到这些内容。

[Seulgi]

你们这流程，只能让人保证 prd 切 feature ，feature 开发完，mr 到 dev 和 uat 测试，改 bug 还是在 feature 改，改完继续 mr 到 dev 和 uat ，测试完成后上线，feature 提 mr 到 prd 删除 feature 。这个流程就是保证 dev/uat 测试的 mr feature 版本和最后 mr 到 prd 的 feature 版本一致，避免在测试中途有人提交了代码到 feature ，最后没过验证直接 mr 到 prd 。

[milukun]

@Asjun 对 我是觉得每次去分支上修改环境的值很奇怪，而且有好几个地方，所以我就用了最笨的方法拉对应分支再去改我的内容，因为这个项目我也是临时参与，没办法确保我去做变量改动是否正确

[asasjajsajsd]

我感觉第一步从 dev 切分支代码就有问题，dev 应该很乱，各种上不上线的代码乱飞的，没法直接推 prd 吧； 所以你们要删 feature/120 分支吧； 其实规定全部从 PRD 切分支，这个问题会好一点