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

Git 三大分支策略, 2 个人的前端团队,开发一个中型应用,适合用哪种策略

  •  
  •   unt · 2022-07-13 22:01:45 +08:00 via iPhone · 3063 次点击
    这是一个创建于 624 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在哪种策略比较主流,易于操作
    34 条回复    2022-07-15 02:14:35 +08:00
    zhlxsh
        1
    zhlxsh  
       2022-07-13 22:17:23 +08:00 via iPhone
    那三大?
    1217950746
        2
    1217950746  
       2022-07-13 22:19:04 +08:00   ❤️ 1
    unt
        3
    unt  
    OP
       2022-07-13 22:22:13 +08:00 via iPhone
    @1217950746 先赞为敬
    unt
        4
    unt  
    OP
       2022-07-13 22:22:33 +08:00 via iPhone
    @zhlxsh gitflow githubflow gitlabflow
    1217950746
        5
    1217950746  
       2022-07-13 22:23:58 +08:00
    @unt 这个分支结构更加简单和灵活,我之前用 gitflow 比较多,后来就换这种简单结构了(不全用)
    1217950746
        6
    1217950746  
       2022-07-13 22:25:37 +08:00
    @unt 更多的时候,我会选择 Rebase 干掉 Merge xxxx 之类的记录
    AngryPanda
        7
    AngryPanda  
       2022-07-14 01:05:53 +08:00 via iPhone
    人少的话,我投 gitlab flow 一票
    Vaspike
        8
    Vaspike  
       2022-07-14 08:53:06 +08:00
    请问各自 fork 一个主仓库然后各自向主仓库 pull request(merge request)的方式有啥名字不
    guchengzhihuan
        9
    guchengzhihuan  
       2022-07-14 09:07:41 +08:00   ❤️ 2
    一人一个开发分支,做好了往主分支合并就完了
    gzyguy
        10
    gzyguy  
       2022-07-14 09:28:30 +08:00 via iPhone
    @Vaspike github flow 吧
    caixiangyu17
        11
    caixiangyu17  
       2022-07-14 09:32:11 +08:00
    trunk based development
    unco020511
        12
    unco020511  
       2022-07-14 09:59:58 +08:00
    很简单,一个主分支,n 个 feature 分支,通过 mr(pr)往主干合
    jones2000
        13
    jones2000  
       2022-07-14 10:13:02 +08:00   ❤️ 1
    就 2 个人还要什么策略,各管各开发。2 个人负责独立的模块,不要有耦合,交互定义好接口协议或接口函数就行了。后期联调就完事了。
    leiuu
        14
    leiuu  
       2022-07-14 10:35:18 +08:00   ❤️ 1
    这种 case 简单的主干开发模式可能比较适合 这三个都不用
    janus77
        15
    janus77  
       2022-07-14 11:14:50 +08:00   ❤️ 1
    2 个人不是 master 一把梭?还有策略?
    justicelove
        16
    justicelove  
       2022-07-14 11:24:25 +08:00
    赞楼上
    unt
        17
    unt  
    OP
       2022-07-14 12:05:29 +08:00 via iPhone
    @jones2000
    @janus77 哈哈,两个人很多了(哭泣),最近在招人,差不多 4 个人,长期项目
    unt
        18
    unt  
    OP
       2022-07-14 12:07:19 +08:00 via iPhone
    谢谢,全赞了一遍
    zhuweiyou
        19
    zhuweiyou  
       2022-07-14 13:07:22 +08:00
    直接主分支开发
    seth19960929
        20
    seth19960929  
       2022-07-14 13:32:44 +08:00
    上面的人都是疯了吗, 直接 master 开发, 这要是代码还在测试有 bug 继续修复怎么上.
    我个人认为比较实用的

    master => prod
    dev => 测试

    A, B 开发者(对于你们两个人)
    开发新功能就从 master checkout 一个 feature 分支. 然后开发完成推到线上, 合并到 dev 分支, 然后部署到测试环境.

    测试通过验收后, feature 分支合并到 master 分支, 部署线上
    jones2000
        21
    jones2000  
       2022-07-14 14:11:10 +08:00
    @unt 2 个人垒界面就够累的了,更不要提核心模块的研发了, 没有核心技术就靠开源堆出来的东西,没有门槛,也没有竞争力,路走不长的。
    unt
        22
    unt  
    OP
       2022-07-14 14:16:20 +08:00
    @jones2000 #21 这你不用担心的,公司挺有钱的,不靠我们挣钱
    unt
        23
    unt  
    OP
       2022-07-14 14:18:32 +08:00
    😩 😩 说错了说错了,4 个人的团队
    qwerthhusn
        24
    qwerthhusn  
       2022-07-14 14:23:06 +08:00
    一两个人,就 master 一条路走到黑
    AyaseEri
        25
    AyaseEri  
       2022-07-14 15:11:45 +08:00
    dev 一条,qa 一条,master 一条。
    一路 rebase 走到底。
    karott7
        26
    karott7  
       2022-07-14 15:14:04 +08:00
    说一条 master 分支走到黑的也太狠了吧,个人觉得一个长期项目即使是一个人开发也最好遵循某一个分支开发流程
    laolaowang
        27
    laolaowang  
       2022-07-14 16:12:55 +08:00
    我司 是 master / feature-*** 足矣
    mazai
        28
    mazai  
       2022-07-14 16:59:40 +08:00
    我司是主仓库 master ( pord ),dev ( test ,uat )两个分支

    每个开发 fork 主仓库到自己的仓库,在自己的仓库开发,push 之后,提交 PR 到主仓库,给领导 CR ,没问题就合并到主仓库的 dev 分支。

    功能 dev 完毕没问题,就合并到主仓库的 master 分支,发布环境。
    fpure
        29
    fpure  
       2022-07-14 17:27:55 +08:00
    直接一个主分支,小改动就直接在上面改,大改动就建个新分支改完合并
    unt
        30
    unt  
    OP
       2022-07-14 18:48:04 +08:00 via iPhone
    @fpure 你走吧,你是 1 铜币都不想要
    u823tg
        31
    u823tg  
       2022-07-14 22:31:27 +08:00
    @unt #30 楼上说的也没多大错, 两个人太复杂的策略目测是坚持不下来的。 太复杂也会降低你们开发效率, 一个人在 n 个 feature n 个 fix dev master 切换。 人少精简点别自己给自己找麻烦。 人多了可以上那些开发策略
    imycc
        32
    imycc  
       2022-07-14 22:33:33 +08:00
    以前用的 gitflow ,实践中开始往 gitlab flow 靠,我觉得还行。
    用 gitflow 最麻烦的问题是长生命周期的分支,在合并的时候会引入大量的差异,做 Code Review 很累人。尽量细化功能分支、多提交,多跟进主分支,能一定程度缓解问题。
    同时去看了一些人在推荐的 trunk based development ,理念也不错,但要求不低。团队人力充足、有专职测试、发布频繁的,可以试试。
    GiantHard
        33
    GiantHard  
       2022-07-14 22:47:39 +08:00
    投 trunk based development 一票,记得完善自动化测试
    msg7086
        34
    msg7086  
       2022-07-15 02:14:35 +08:00
    trunk based development 这个比较适合传统开发模式。
    敏捷开发一般保证 dev/master 是随时可用,feature 上做功能。
    传统开发一般保证 release/*是随时可用,dev/master 上做功能。(当然还是要配合 personal branch+MR 。)
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   961 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 21:46 · PVG 05:46 · LAX 14:46 · JFK 17:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.