首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Idealyouth
V2EX  ›  程序员

多人开发同一个项目且每人进度不一样,上线时间不一样 git 应该使用什么样的流程?

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

    目前是有 dev、pre、master 分别是测试、预生产、生产

    目前流程是这样的
    1.每个人开发新功能时基于 master 切出新分支 feature_xxx 开发完成时合并到 dev
    2.测试没问题再将 feature_xxx 合并到 pre
    3.预生产没问题再将 feature_xxx 合并到 master

    这样的流程感觉 pre 预生产没有存在的必要,预生产应当是直接合并到 master 上的

    请问多人开发同一个项目,且每个人的上线时间点都不一样,还有当代码已经提交到预生产了,却又延迟上线,另一个人却提前上线的

    这种应该使用怎样的 git 流程?

    22 回复  |  直到 2019-12-28 10:21:24 +08:00
    Allianzcortex
        1
    Allianzcortex   54 天前
    我们的做法是只有 dev 作为测试环境和 master 作为生产环境,用 netlify 来部署 Preview feature 做 PR。每个人的上线时间点都不一样这应该是常态啊,除非一个人的任务被另一个人 block 住都没什么问题吧
    seki
        2
    seki   54 天前
    我们是用一个统一的配置来控制每个 feature 的开关或者灰度的,只要测试验证通过,每个人都可以一个一个提交往 master 上合并
    msg7086
        3
    msg7086   54 天前
    Staging 应该是上线前的最后一道门槛。如果要上线的 feature 改了,那么就应该重做 Staging 分支,只包含要上线的 feature 来测试。

    Git 是很灵活的,不要把他用得那么死板。如果一个分支不适合当前需求了,就重建这个分支。
    br00k
        4
    br00k   54 天前 via iPhone
    git fkow
    luozic
        5
    luozic   54 天前 via iPhone
    feature 之间有无依赖或者冲突,没有矛盾或者冲突,并且数据独立性较好,可以一个个上线,gitFlow+CI/CD 就是干这事的。
    finian
        6
    finian   54 天前
    目前的流程没问题啊。问题点在哪儿?
    sagaxu
        7
    sagaxu   54 天前 via Android
    有人插队先发就让他发,后发的人 rebase 到新发的 master 上
    ducklyl
        8
    ducklyl   54 天前
    去掉 pre,保留 dev 和 master 即可。
    Hyseen
        9
    Hyseen   54 天前
    不需要 pre 分支
    Kylinsun
        10
    Kylinsun   54 天前
    @br00k git flow
    JJstyle
        11
    JJstyle   54 天前 via iPhone
    我们是两周一个开发周期,不存在你的功能先做完就先上线,大家最后都会合到一个分支里,统一测试、上线。

    有人会说要是我的功能一周就做完了是不是下周可以划水一周了呢?那宁难道不会工作半天划水半天吗
    earthyan
        12
    earthyan   54 天前
    并不需要 pre 分支,不存在先后关系。merge PR 的时候,记得 rebase 分支就 ok
    Bigglesworth
        13
    Bigglesworth   54 天前
    @JJstyle #11 666 学到了
    Huizhen
        14
    Huizhen   54 天前
    @JJstyle 学到了
    DelayNoMore
        15
    DelayNoMore   54 天前
    @JJstyle 我每天都是半天工作,半天划水状态
    wangyzj
        16
    wangyzj   54 天前
    Gitflow
    passerbytiny
        17
    passerbytiny   54 天前
    每个人开发新功能时都切出新分支,这种情况下,最没必要的不是 pre,而是 dev。

    在 feature_xxx 上做单元测试,生成 PR ;在 pre 上做集成测试和系统测试,发布预览版本;在 master 分支上再次做集成测试和系统测试,发布稳定版本。上面的合并方向是 feature_xxx→pre→master。如果不需要同时发布预览版本和稳定版本,则取消 pre 分支,feature_xxx 直接向 master 合并。

    Github 流程就是单中央分支的。

    你现在的流程是有隐患的:测试、预生产用得是 dev、pre 分支,但合并过去的是 feature_xxx 分支。
    binux
        18
    binux   54 天前
    单一主线原则:保证 master 分支(你这里是 dev )处于随时可上线发布状态。
    如果有任何分支并入会改变这个状态,则先,将任何有相互依赖的 feature 分支先合并再以单一 PR 并入 master。
    如果合并后有 bug 使其变为无法发布状态,先 revert 再发布。

    预生产本来就是团队的主观决定,一般预生产比测试环境更稳定这样。

    另外我们发布是用 tag,比如 staging-1, demo-2, production-3 这样,我觉得比 branch 好很多。
    yang2yang
        19
    yang2yang   54 天前
    只能说楼主家做法的跟我司基本上一致的
    zydrsnuo
        20
    zydrsnuo   54 天前 via Android
    我们的流程也是这样的,拉一个新分支开发,然后合并到 dev 联调测接口,之后再合并到 pre 测整体功能和 bug。理论上 dev 是可以省略的,因为可以在新拉出来的分支上联调,然后直接合并到 pre。但是我们有个自动编译和部署的系统,合并到 dev 是为了通过它自动部署到测试环境。
    xavierchow
        21
    xavierchow   53 天前   ❤️ 1
    https://xavierchow.github.io/talk_git_branch_model/#/
    ^这是我在公司推行 git flow 时的一个讲座的资料, 有图比较容易懂,希望能帮助到你。
    homecoming
        22
    homecoming   53 天前
    不是说开发完了就会上线,多人合作,会有一个版本/迭代的概念。
    功能开发拉 feature 分支,开发完了,给 QA 进行功能测试
    功能测试完成,进入集成分支(版本分支),进行集成测试(功能开发完了,因为依赖方不 OK,或者其他问题,可能会延期,这种 feature 不进入集成,一旦进入集成,原则上必须这个版本上线。)
    集成测试完成,进入 release (预发布)分支,进行线上验证,老版本兼容验证等。
    验证完成,进入 master 分支,再次验证,然后线上灰度放量。

    如果灰度过程中,发现问题,从 master 拉出 hotfix,修复、验证以后 ,合并进入 master.

    这种模型,还可以进行多版本同时开发。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3870 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 06:52 · PVG 14:52 · LAX 22:52 · JFK 01:52
    ♥ Do have faith in what you're doing.