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

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

  •  
  •   Idealyouth · 2019-12-27 02:11:26 +08:00 via iPhone · 5083 次点击
    这是一个创建于 1553 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

    这种模型,还可以进行多版本同时开发。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5302 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 09:17 · PVG 17:17 · LAX 02:17 · JFK 05:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.