这是一个创建于 363 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前一个项目，线上是有 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 和 环境变量
（ 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 和 环境变量
 |
1
ztxcccc 363 天前
dev 和 uat 代码不一样，那每个环境做的集成测试不是白做了？
|
 |
2
zjp 363 天前 via Android
流程就不合理很难说有什么好的操作办法…
在没有功能开发进行中时，三个分支的代码应该是一样的。环境变量用构建工具/配置中心管理 第三步到合并 prd 应该是自动化的，手工合代码不能保证最终 prod 的代码和 uat 一致，这样测试有没有意义很值得怀疑 |
 |
3
Ljxtt 363 天前 via Android
后面的不直接 cherry pick 吗？还是说连改动的代码都不一样？
|
 |
5
milukun OP @Ljxtt 实际情况比题目中的复杂度 double 一下，因为项目有两个线上版本（需求不同，显示内容不同之类的），因此有 6 个分支
dev 、uat 、prd dev-r 、uat-r ，prd-r 也就是上面的操作其实我要做 6 次😅 |
 |
8
tianmalj0613 363 天前  1
环境变量,url 什么的，直接放代码里面？
和环境有关的东西应该放在部署里面，你们这个和代码耦合很明显不合理啊 |
 |
9
cnoder 363 天前
dev 、uat 、prd 应该是一个分支
|
 |
10
admol 363 天前
步骤 1 、2 后不要自动删除 feature 分支，第 3 步完成后再删除。
分支合到 dev 和 uat 后不会再回来修改 feature 分支上的 BUG ，为什么要马上删除？ |
 |
11
leonshaw 363 天前
rebase --onto
|
 |
13
dzdh 363 天前
prd 主干
dev 开发 开发都是从 prd 切 feature 分支，合并到 dev ，dev 测试没问题，feature 合到 prd 。 环境变量参考 laravel/flask env 。项目代码从 configrepository 获取配置，configrepository 从 env 读取 |
 |
15
Habyss 363 天前
总有一个稳定的基本线上分支吧 比如 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 分支 |
|
16
milukun OP @admol 因为 dev 合并完，我要推基于 uat 的 feature/120 分支上去呀（分支名相同），前提是 dev 和 uat 代码不一致，所以没办法直接一个 feature/120 合并三次，如果可以就没有这个题目了
|
 |
17
shaozelin030405 363 天前
dev 和 uat 的代码 merge 一下，conflict 处理一下。哪天 dev 和 uat 的行为不一致有够你们受的。
|
 |
18
devopsdogdog 363 天前
因为 dev 和 uat 的代码不是完全相同的，非常蛋疼的在里面有写死的 api-url 和 环境变量
有这些骚操作的，git 流程有问题不奇怪， 应该是 dev new 个新分支。 合并到 dev ,然后 dev 合并到 uat 。uat 直接合并 prd 吧 感觉没有基线。 你独立推送，感觉像是使用 svn ... |
 |
19
unco020511 363 天前
环境应该都基于一份相同的代码,然后用其他工具在部署打包的时候来区分环境
|
 |
20
thevita 363 天前
cherry-pick
歪楼: “三个分支代码基本是一样的，只是里面可能部分标记环境的变量不同“ 这种情况应该首选通过 flag 来实现 手动处理最大的问题是: 一段时间之后，就没人知道这三个分支 除了 “部分标记环境的变量不同” 外是不是真的完全一样了 再次的选择: 引入一些 自动化的工作流, 如: merge 到 dev 的 feature 合并后，自动创建 到 uat, prd 的 mr |
 |
21
wjfz 363 天前
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 ，完成。 在这个流程中，只要需求不牵扯环境变量的修改，就不用操心环境的事情。 |
 |
22
zoharSoul 363 天前
什么奇怪的流程....
|
 |
23
libook 363 天前
建议环境变量不放在 Git 项目里。
我们团队几年前做过一次安全治理，环境变量里大多是数据库、中间件之类的连接地址和访问凭据，为了避免隔三差五被人误发到公共 git repo 上去，要求仅负责部署的运维人员可以看到，所以全部信息都从 git 项目里剥离，并重置所有认证信息。这样使用云原生部署的话可以使用配置中心或者 k8s 的 secret 机制来比较方便和安全地管理。 只要不放在 git 项目里，那么几个分支就是可以互相合并的了。而且可以追踪每个 feature 是什么时候、什么人开发、合并到测试分支、合并到生产分支上的。 如果按照你们的使用方式，你可以使用 rebase 将一个 feature 里的所有提交合并成一个提交，再 cherry-pick 到下游分支上，就是这种做法因为没有记录 merge 操作，所以三个分支之间没有联系，你需要自己去比对 commit message ，同时因为使用了 rebase 合并了提交，导致开发过程中的提交历史细节被丢弃。 |
 |
24
Asjun 363 天前
我现在也有个项目这样，一些环境变量是在仓库里写死的。分 prod, staging, dev 三个分支。
但我提交的逻辑是，feature -> dev -> staging -> prod ，就单纯的提交 MR 后合并即可。 环境变量部分： 1. 先修改 dev 分支，提交一次； 2. 然后合并到 staging 分支，切换到 staging 分支，再修改成 staging 环境的值，提交； 3. 继续合并到 prod 分支，切换为 prod 分支，再修改成 prod 环境的值，提交。 如果修改的代码里不涉及这些冲突的内容，合并时不会影响到这些内容。 |
 |
25
Seulgi 363 天前
你们这流程，只能让人保证 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 。
|
|
26
milukun OP @Asjun 对 我是觉得每次去分支上修改环境的值很奇怪，而且有好几个地方，所以我就用了最笨的方法拉对应分支再去改我的内容，因为这个项目我也是临时参与，没办法确保我去做变量改动是否正确
|
 |
27
asasjajsajsd 363 天前
我感觉第一步从 dev 切分支代码就有问题，dev 应该很乱，各种上不上线的代码乱飞的，没法直接推 prd 吧； 所以你们要删 feature/120 分支吧； 其实规定全部从 PRD 切分支，这个问题会好一点
|
Select Language