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

你们 gitlab 多人开发项目是走 fork 还是原始项目新建分支?

  •  
  •   hanyceZ · 2021-12-08 17:23:16 +08:00 · 4741 次点击
    这是一个创建于 841 天前的主题,其中的信息可能已经有所发展或是发生改变。
    37 条回复    2021-12-10 13:40:07 +08:00
    abigeater
        1
    abigeater  
       2021-12-08 17:24:14 +08:00
    原始项目新建分支
    hanyceZ
        2
    hanyceZ  
    OP
       2021-12-08 17:32:12 +08:00
    @abigeater 我是一直在走 fork 的流程,原始项目禁止提交,只能走 mr 。感觉原始项目新建分支并不如 fork 好啊,可以说下为什么在用吗
    wolfie
        3
    wolfie  
       2021-12-08 17:58:08 +08:00
    @hanyceZ #2
    A B 两人 并行开发,A 依赖 B 未合并功能。Fork 出来的应该怎么处理。
    villivateur
        4
    villivateur  
       2021-12-08 17:59:09 +08:00 via Android
    @wolfie 发起反向的 pr
    hanyceZ
        5
    hanyceZ  
    OP
       2021-12-08 18:01:38 +08:00
    @wolfie B push 到他 fork 下来的项目上去,A 去 pull B fork 来下的仓库即可
    villivateur
        6
    villivateur  
       2021-12-08 18:04:12 +08:00 via Android
    @abigeater 你这样做的话,分支的意义就不明确了,按理来说,不同分支应该代表不同的开发进度或者功能适配点,而不是每个人都开发进度
    sunny352787
        7
    sunny352787  
       2021-12-08 18:04:30 +08:00   ❤️ 4
    新建分支,master 分支保护,合并发起 mr 审核
    hanyceZ
        8
    hanyceZ  
    OP
       2021-12-08 18:06:41 +08:00
    @sunny352787 我觉得这种方式,开发人员变多的话,分支就会很难看,就会有各种各样基于某某某的分支衍生出来,fork 下来的原始项目会稍微干净一些吧
    wolfie
        9
    wolfie  
       2021-12-08 18:10:29 +08:00
    @villivateur #4
    @hanyceZ #5
    如果一个项目 10 个人 开发,10 个人 之间都有可能有交际,可能要维护 10 个 remote 。
    Goooler
        10
    Goooler  
       2021-12-08 18:11:39 +08:00
    都是 maintainer 了还需要 fork 吗,这也太没牌面了吧
    deplivesb
        11
    deplivesb  
       2021-12-08 18:13:19 +08:00
    分支啊,fork 怎么解决 彼此依赖的问题?
    我司的有的大型的项目都是几百个分支
    sunny352787
        12
    sunny352787  
       2021-12-08 18:17:14 +08:00
    @hanyceZ 没啥区别,fork 还多了一些操作,想操作别人正在修改的东西也太麻烦了,为了分支洁癖给自己制造障碍没啥必要,该走的分支合并审核 CI 流程走好了就行了
    villivateur
        13
    villivateur  
       2021-12-08 18:29:40 +08:00
    @wolfie 维护一个主线仓库,其他仓库都往这个主线仓库提 PR 不就行了
    xuanbg
        14
    xuanbg  
       2021-12-08 18:36:25 +08:00
    1 人 1 分支,开发完的合并到 test 分支进行测试。
    timothyye
        15
    timothyye  
       2021-12-08 18:41:12 +08:00
    fork 不推荐,禁止直接 push 或者 merge 到 master ,每次开发都从 master 新建分支,通过代码 review 之后再 merge 回 master
    CoCoMcRee
        16
    CoCoMcRee  
       2021-12-08 18:53:42 +08:00
    拉一个用于迭代的 test 分支. test 分支设置保护只有 MR 权限, 禁止直接 PUSH.
    多人开发就拉取多个 dev 分支.

    每次代码提交都按照流程走.
    比如 ABC 三人同时开发.
    A 今天开发了一点, 先把远端 test 合并到本地 A-dev. 有冲突解决冲突. 然后到 gitlab 上把 A-dev 合并到 test, 同时指派给领导(或自己)进行 CodeReview. 没问题了就同意合并.
    同理.
    B 或 C 今天开发了一点功能, 也是先把远端 test 合并到本地 B-dev. 有冲突解决冲突. 然后到 gitlab 上把 A-dev 合并到 test, 同时指派给领导(或自己)进行 CodeReview. 没问题了就同意合并.


    这样做的好处是, 所有人都在提交代码前要把 test 拉取到本地, 这样就会有其他所有人的代码. 同时需要本地解决冲突. 保证远端代码是不会冲突的. 才能通过 MR 合并到 test 上.

    每次要发布测试版都从 test 上发.
    Jwyt
        17
    Jwyt  
       2021-12-08 19:06:32 +08:00
    走 fork 多麻烦啊,这不是给自己找事么
    kidonng
        18
    kidonng  
       2021-12-08 21:57:57 +08:00 via Android   ❤️ 1
    10L 在理,fork 存在的主要意义是为了让没有 write access 的人能够有地方提交代码,有 write access 的话 fork 是完全没有必要的。
    risky
        19
    risky  
       2021-12-08 22:32:02 +08:00   ❤️ 1
    既然都 gitlab 了, 为什么不试试 gitlab flow + rebase 呢?
    Mystery0
        20
    Mystery0  
       2021-12-09 00:36:06 +08:00 via Android
    @CoCoMcRee 我司最开始也是这么玩的,但是一直以来有一个问题:多人共同对一个项目进行开发,各自负责一个 feature ,所有人都在开发阶段提交代码到 test 上,当其中有一个 feature 提测之后,就需要部署到提测环境,只是直接部署 test 分支就会把其他人还处于开发中的代码一并部署,然后其他人的 feature 被迫“提测”。请问对于这种情况怎么解决呢
    Fule
        21
    Fule  
       2021-12-09 08:58:55 +08:00
    @Mystery0, 每人一个 feature 应该是每人工作在各自的 feature branch 上吧,只有完成了当前 feature 才合并或 rebase 代码到 test branch 上,这样才可以确保 test branch 上没有未完成的代码。如果有一个 feature 依赖于另一个 feature 的代码,那么只能把这 2 个 feature 都分配给同一个人或者必须等被依赖的 feature branch 并入 test branch 之后另一个 feature branch 再从 test branch 上得到依赖的代码。
    iosx
        22
    iosx  
       2021-12-09 09:13:58 +08:00 via iPhone
    @Mystery0 #20 @Mystery0 #20 我们是个人从 dev 拉分支 feat-dev 开发,确认可以提测了再 mr 到 dev 分支,此时 ci 自动生成测试版本,测试通过且 codereview 通过再确认 mr 。当然前提最好是每个人开发的功能模块是独立的。
    abigeater
        23
    abigeater  
       2021-12-09 09:25:55 +08:00
    @hanyceZ
    @villivateur
    刚看到,按我理解分支就是从某个分支用来新增功能或修复 BUG ;开发人员是没有直接提交 master 权限提交 mr 等待被合,正如 villivateur 说,每个分支代表不同的功能点开发或者某个 BUG 的修复(我们也正是这样做)。分支合进了主分支后就删掉远程分支,本地删不删就没所谓了。

    另外我的理解 fork 更像是不同人直接的协作,而团队内并不像这样的形式(像楼上说之间功能有依赖关系 fork 更麻烦
    Mystery0
        24
    Mystery0  
       2021-12-09 10:10:41 +08:00
    @Fule 这样其实也可以,但是 leader 说这样就有太多的 feature 分支了,下一季度我尽量往这方面推吧
    Mystery0
        25
    Mystery0  
       2021-12-09 10:12:37 +08:00
    @Fule
    @iosx
    突然想起来一个事情,这样子岂不是需要大于等于 feature 数量的开发联调环境,目前我司就 3 个环境,一个开发、一个测试、一个预生产,按照 feature 拆分的话,在季度开发前期,开发环境不够用
    zhouxuchen
        26
    zhouxuchen  
       2021-12-09 10:22:48 +08:00
    @Mystery0 #20 我们仨分支,master 、canary 、develop ,feature 分支能够直接 merge 到 develop ,且能 push ,方便开发测试; master 分支和 canary 分支仅接受 mr ,且 canary 分支仅接受 feature 分支的 mr ,master 仅接受 canary 的 mr ;如果要上 canary 分支就表示这个功能在 develop 上由测试确认可以上线,上了 canary 之后再由产品验收,因为验收一般就跑个冒烟用例,要不了很久,基本不会卡流程;坏处就是 develop 上有大量因为管理层拍脑袋而夭折的需求……
    thevita
        27
    thevita  
       2021-12-09 11:32:22 +08:00
    fork 和 feature branch 在这里有太大区别么,不都通过 mr 来合并?,反而更复杂不方便协作。

    至于说多人维护同一个 feature 分支的的协作问题,我个人倾向是下 feature 粒度,快速合并,尽量减少这种情况,同时尽量避免长期不能合并的 mr ,当然这更项目架构,团队架构都有关系,就比较复杂了,也一定对,,适合自己的才是最好的。
    DeWhite
        28
    DeWhite  
       2021-12-09 12:20:56 +08:00 via iPhone
    ...
    开个新分支,然后开发完 rebase 。
    msg7086
        29
    msg7086  
       2021-12-09 13:38:23 +08:00   ❤️ 1
    Fork 就是陌生人之间的 feature branch 。一个团队里要什么 fork ,除非是你自己折腾仓库完,正常的开发完全没必要用 fork 。太多的 feature branch 又怎么了,又不收你钱。Merge 以后分支就删了。
    vincent7245
        30
    vincent7245  
       2021-12-09 14:34:51 +08:00
    feature -> dev -> sit -> uat -> master
    uat 和 master 的合并都要审核
    vincent7245
        31
    vincent7245  
       2021-12-09 14:36:31 +08:00
    aHR0cHM6Ly93d3cuY25ibG9ncy5jb20vc2NhankvcC8xMTUxNDQzNi5odG1sCg==
    这篇博客介绍的很详细
    wannaspring
        32
    wannaspring  
       2021-12-09 14:38:26 +08:00
    @vincent7245 来个链接。。
    itfisher
        33
    itfisher  
       2021-12-09 17:07:17 +08:00
    @Mystery0 你们是那种大型需求嘛?我们这边都是每个人 feature 分支开发自测没问题,才提交到公共测试分支发布在测试环境(有冲突至少在测试阶段就能知晓了),测试分支没问题再提预发布测试,预发布没问题提 mr 。我理解大部分公司应该都是这个流程吧?
    Mystery0
        34
    Mystery0  
       2021-12-09 18:38:57 +08:00 via Android
    @itfisher 一个季度的需求有 20-30 个吧,每个 feature 一个分支的话,太多了
    Fule
        35
    Fule  
       2021-12-09 19:52:59 +08:00
    @Mystery0, feature 分支属于“私人分支”,换句话说,人在 feature 分支里玩儿出花来也没关系,它并不参与 CI 过程也不会共享代码给别人,当某个 feature 在 feature 分支完成之后会 rebase 到最新的 test 分支并压缩成唯一提交(如果 feature 分支上有多个提交的话)然后提交 PR 到 Test 分支。一旦 feature 分支合并到了 test 分支,这个 feature 分支就可以删掉了。如果那个 feature 在 test 分支上测试时出现了问题,那么基于最新 test 分支重新创建一个新 feature or bugfix 分支进行处理,并重复之前的过程。

    如果出现多个 feature 需要并行共享代码联调,那么我觉得有两种方法:

    1. 所有 feature 功能实现划分可能需要优化或细化,变成多阶段处理,每阶段可以无(大量)互相依赖在各自独立开发,然后下一阶段可以依赖前一阶段的代码
    2. 多 feature 共享的代码部分可以交予一名主程直接在 test 分支上开发,然后其它各个 feature 分支随时 rebase test 分支。
    Mystery0
        36
    Mystery0  
       2021-12-09 22:00:29 +08:00 via Android
    @Fule 但是很多 feature 分支的话,开发环境不够,代码开发可以本地就完成,多数 feature 开发完毕之后需要部署到开发环境和其他服务(前端)联调。你说的 feature 开发,完毕之后合并到 test ,且丢掉原 feature 分支,如果出现问题以 patch 的形式修改,这个感觉可以借鉴一下。
    asuraa
        37
    asuraa  
       2021-12-10 13:40:07 +08:00
    git-flow 瞭解一下
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5191 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 01:22 · PVG 09:22 · LAX 18:22 · JFK 21:22
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.