V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
milukun
V2EX  ›  git

一个关于 GIT 提交的疑问?

  •  
  •   milukun · 175 天前 · 2758 次点击
    这是一个创建于 175 天前的主题,其中的信息可能已经有所发展或是发生改变。
    目前一个项目,线上是有 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 和 环境变量
    27 条回复    2023-11-27 17:58:25 +08:00
    ztxcccc
        1
    ztxcccc  
       175 天前
    dev 和 uat 代码不一样,那每个环境做的集成测试不是白做了?
    zjp
        2
    zjp  
       175 天前 via Android
    流程就不合理很难说有什么好的操作办法…
    在没有功能开发进行中时,三个分支的代码应该是一样的。环境变量用构建工具/配置中心管理
    第三步到合并 prd 应该是自动化的,手工合代码不能保证最终 prod 的代码和 uat 一致,这样测试有没有意义很值得怀疑
    Ljxtt
        3
    Ljxtt  
       175 天前 via Android
    后面的不直接 cherry pick 吗?还是说连改动的代码都不一样?
    milukun
        4
    milukun  
    OP
       175 天前
    @Ljxtt 之前完全没有过这样的场景😢 我去学习一下 cherry pick
    milukun
        5
    milukun  
    OP
       175 天前
    @Ljxtt 实际情况比题目中的复杂度 double 一下,因为项目有两个线上版本(需求不同,显示内容不同之类的),因此有 6 个分支
    dev 、uat 、prd
    dev-r 、uat-r ,prd-r
    也就是上面的操作其实我要做 6 次😅
    ztxcccc
        6
    ztxcccc  
       175 天前
    @milukun 你不同分支代码不一样/不是 merge 上去的话,不一定能用 cherry-pick
    milukun
        7
    milukun  
    OP
       175 天前
    @ztxcccc #6 dev 、uat 、prd 这三个分支上,我自己的改动是完全一样的,只是三个分支本身其他代码会有区别
    tianmalj0613
        8
    tianmalj0613  
       175 天前   ❤️ 1
    环境变量,url 什么的,直接放代码里面?
    和环境有关的东西应该放在部署里面,你们这个和代码耦合很明显不合理啊
    cnoder
        9
    cnoder  
       175 天前
    dev 、uat 、prd 应该是一个分支
    admol
        10
    admol  
       175 天前
    步骤 1 、2 后不要自动删除 feature 分支,第 3 步完成后再删除。
    分支合到 dev 和 uat 后不会再回来修改 feature 分支上的 BUG ,为什么要马上删除?
    leonshaw
        11
    leonshaw  
       175 天前
    rebase --onto
    Katrol
        12
    Katrol  
       175 天前
    @milukun 自己改动一样 那就 cherry pick 过去,有冲突再解决
    dzdh
        13
    dzdh  
       175 天前
    prd 主干
    dev 开发

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

    环境变量参考 laravel/flask env 。项目代码从 configrepository 获取配置,configrepository 从 env 读取
    ztxcccc
        14
    ztxcccc  
       175 天前
    @milukun #7 和是不是你的没有关系,主要是你控制不了别人,这才需要一级一级的 PR
    Habyss
        15
    Habyss  
       175 天前
    总有一个稳定的基本线上分支吧 比如 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
        16
    milukun  
    OP
       175 天前
    @admol 因为 dev 合并完,我要推基于 uat 的 feature/120 分支上去呀(分支名相同),前提是 dev 和 uat 代码不一致,所以没办法直接一个 feature/120 合并三次,如果可以就没有这个题目了
    shaozelin030405
        17
    shaozelin030405  
       175 天前
    dev 和 uat 的代码 merge 一下,conflict 处理一下。哪天 dev 和 uat 的行为不一致有够你们受的。
    devopsdogdog
        18
    devopsdogdog  
       175 天前
    因为 dev 和 uat 的代码不是完全相同的,非常蛋疼的在里面有写死的 api-url 和 环境变量

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

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

    感觉没有基线。 你独立推送,感觉像是使用 svn ...
    unco020511
        19
    unco020511  
       175 天前
    环境应该都基于一份相同的代码,然后用其他工具在部署打包的时候来区分环境
    thevita
        20
    thevita  
       175 天前
    cherry-pick

    歪楼:

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

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

    再次的选择:
    引入一些 自动化的工作流, 如: merge 到 dev 的 feature 合并后,自动创建 到 uat, prd 的 mr
    wjfz
        21
    wjfz  
       175 天前
    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
        22
    zoharSoul  
       175 天前
    什么奇怪的流程....
    libook
        23
    libook  
       175 天前
    建议环境变量不放在 Git 项目里。
    我们团队几年前做过一次安全治理,环境变量里大多是数据库、中间件之类的连接地址和访问凭据,为了避免隔三差五被人误发到公共 git repo 上去,要求仅负责部署的运维人员可以看到,所以全部信息都从 git 项目里剥离,并重置所有认证信息。这样使用云原生部署的话可以使用配置中心或者 k8s 的 secret 机制来比较方便和安全地管理。

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

    如果按照你们的使用方式,你可以使用 rebase 将一个 feature 里的所有提交合并成一个提交,再 cherry-pick 到下游分支上,就是这种做法因为没有记录 merge 操作,所以三个分支之间没有联系,你需要自己去比对 commit message ,同时因为使用了 rebase 合并了提交,导致开发过程中的提交历史细节被丢弃。
    Asjun
        24
    Asjun  
       175 天前
    我现在也有个项目这样,一些环境变量是在仓库里写死的。分 prod, staging, dev 三个分支。

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

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

    如果修改的代码里不涉及这些冲突的内容,合并时不会影响到这些内容。
    Seulgi
        25
    Seulgi  
       175 天前
    你们这流程,只能让人保证 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
        26
    milukun  
    OP
       175 天前
    @Asjun 对 我是觉得每次去分支上修改环境的值很奇怪,而且有好几个地方,所以我就用了最笨的方法拉对应分支再去改我的内容,因为这个项目我也是临时参与,没办法确保我去做变量改动是否正确
    asasjajsajsd
        27
    asasjajsajsd  
       175 天前
    我感觉第一步从 dev 切分支代码就有问题,dev 应该很乱,各种上不上线的代码乱飞的,没法直接推 prd 吧; 所以你们要删 feature/120 分支吧; 其实规定全部从 PRD 切分支,这个问题会好一点
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5568 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 02:10 · PVG 10:10 · LAX 19:10 · JFK 22:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.