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

咨询各位大佬关于 git 分支的问题

  •  
  •   jzyzcz · 117 天前 · 2052 次点击
    这是一个创建于 117 天前的主题,其中的信息可能已经有所发展或是发生改变。

    想要请教各位大佬一个关于 git 的问题:

    现在公司的开发环境分为: 测试环境, 预生产环境, 生产环境;

    那 git 分支应该如何创建? 是不是每种环境对应一个分支?

    那么开发流程是不是类似下面描述的这样:

    假设, 小王同学要开发一个新的功能, 那么他就先从测试主分支上检出一个本地分支 a, 进行新功能的开发.

    新功能开发完成, 在其本地测试无误后, 合并分支 a 到测试主分支进行测试.

    在测试环境测试完成后, 再把分支 a 合并到预生产分支进行预生产环境的测试.

    预生产环境测试没有问题, 再把分支 a 合并到生产环境分支, 然后发版.

    各位大佬所在公司的 git 开发流程是怎么样的, 可以麻烦给说一下么?

    第 1 条附言  ·  117 天前
    感谢大佬们的回复!


    我补充一下细节, 我现在主要写 vue, vue cli3 支持不同的 model.

    我在项目里配置了三个.env 文件, .env.dev 对应测试环境, .env.pre 对应预发布环境, .env.master 对应生产环境.

    然后在三个环境的服务器上都建了 jenkins.

    三个 jenkins 分别执行 npm run build:dev, npm run build:preview, npm run build:master, 去发布不同环境的代码.
    15 条回复    2019-12-05 14:10:16 +08:00
    fxy739371
        1
    fxy739371   117 天前   ❤️ 1
    你可以了解一下 gitflow,应该是你需要的
    whypool
        2
    whypool   117 天前   ❤️ 1
    是的
    liubo18
        3
    liubo18   117 天前   ❤️ 1
    是的
    jzyzcz
        4
    jzyzcz   117 天前
    @fxy739371 谢谢, 粗略的看了看 gitflow 的介绍, 确实比自己手动逐个建分支合并分支要方便.
    mcfog
        5
    mcfog   117 天前 via Android   ❤️ 1
    不是,git 是源码管理,区分环境是配置管理,想用 git 兼做配置管理,最低限度至少得吧源码和配置分开不同的 repo
    你现有的做法相当于跳过了构建,直接用 git 存放 build artifact,直接在 build artifact 上写代码
    jzyzcz
        6
    jzyzcz   117 天前
    @mcfog 感谢回复!

    我补充一下细节, 我现在主要写 vue, vue cli3 支持不同的 model.

    我在项目里配置了三个.env 文件, .env.dev 对应测试环境, .env.pre 对应预发布环境, .env.master 对应生产环境.

    然后在三个环境的服务器上都建了 jenkins.

    三个 jenkins 分别执行 npm run build:dev, npm run build:preview, npm run build:master, 去发布不同环境的代码.
    creanme
        7
    creanme   117 天前
    顺便想 v 友们一个 git 分支方面的问题,如果新版本某些功能不上线,应该怎么处理比较好呢?
    creanme
        8
    creanme   117 天前
    分支都合并进去了,然后又暂时不上线
    index90
        9
    index90   117 天前   ❤️ 1
    每个环境一个分支,怕不是你把环境配置都和程序代码混合到代码管理里了?

    每个环境独立一个代码分支,每次测试都是白费的。你无法保证合并后的代码能正常工作,所以你又要测一次,每一次合并代码,上一次的测试结果就等于作废。

    正确做法是,各个环境之间传递的都应该是同一个制品,这样你的测试才有意义。环境的配置管理,请使用配置管理系统,或者独立 repo 管理。
    index90
        10
    index90   117 天前
    @creanme 开发时预留特性开关,用配置文件控制。或者不合并,等需要的时候,rebase,集成测试,再合并。
    mcfog
        11
    mcfog   117 天前
    @jzyzcz 所以有不同的 build 命令可以 build 不同环境的包,还有 jenkins 可以管理这些构建过程了,就更不需要用 git 分支来管理环境的差异了
    AstroProfundis
        12
    AstroProfundis   117 天前   ❤️ 1
    同意 #9 楼,应该保证测试、预发、上线的是同一份代码,最好应该是同一个二进制 /包,这样你前面的那些测试才是有意义的;跟环境相关的东西全部从配置文件或者环境变量或者启动参数读取,用外部工具(比如各种 CI 工具)来管理

    这样 git branch 应该只跟你开发期间的功能划分和协作模式有关系,当你决定要发布某个版本的时候从这个位置切出来一个新分支,测试、修 bug, 然后重复一直到验证完成,然后打 tag, 之后拿这个 tag 再走一边测试、预发,然后上线
    shuizhengqi
        13
    shuizhengqi   117 天前
    分支跟环境无关
    Zenyk
        14
    Zenyk   117 天前
    楼上也说了 不是同一份代码测试没有意义 如你目前的方式 在最后上线前仍然需要对最终版代码进行测试
    开发流程的话 一般是本地或远程新建分支 再拉到本地开发 环境可以通过 node 脚本针对不同环境做本地代理
    比如这样 npm start dev/pre/remote
    wangyzj
        15
    wangyzj   117 天前
    看下 gitflow
    然后根据公司现状微调
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3229 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 13:14 · PVG 21:14 · LAX 06:14 · JFK 09:14
    ♥ Do have faith in what you're doing.