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

大家 git 分支流程是怎么样的?

  •  
  •   DingDingDang123 · 2021-11-30 19:56:12 +08:00 · 2787 次点击
    这是一个创建于 1123 天前的主题,其中的信息可能已经有所发展或是发生改变。
    主分支 master:
    开发分支:feature1212
    测试分支:dev

    案例:12 月 12 号有一个迭代(有多个功能)要上线,有两位开发同学参与( A,B )同时开发。
    目前有两种分支管理模式:

    ## 方案一:
    - 从 master 拉 feature1212 分支
    - 开发阶段:开发 A , 开发 B 共用 feature1212 开发
    - 测试阶段:feature1212 merger 到 dev , dev 进行测试 // 当 dev 分支有变更,会通过自动部署
    - 部署线上阶段:feature1212 merge 到 master



    ## 方案二:
    - 从 master 拉 feature1212 分支
    - 开发阶段:开发 A , 开发 B 再分别从 feature1212 拉自己的分支,比如:featue1212A, feature1212B // 1. 共用代码不好复用
    - 测试阶段:从自己的开发分支 merge 到 dev // 问题:1. 当 dev 分支有变更,会通过自动部署,导致多次构建 2. 这里可能有冲突,需要解决
    - 合并冲突阶段:feature1212A ,feature1212B 分别 merge 到 feature1212 // 问题:1. 这里还要再解决一次冲突
    - 部署线上阶段:feature1212 merge 到 master
    7 条回复    2021-12-01 16:04:08 +08:00
    hlwjia
        1
    hlwjia  
       2021-11-30 20:18:15 +08:00
    yl20181003
        2
    yl20181003  
       2021-11-30 23:23:10 +08:00 via Android
    git-flow
    gzf6
        3
    gzf6  
       2021-12-01 08:36:27 +08:00 via Android
    Trunk base
    CasualYours
        4
    CasualYours  
       2021-12-01 09:14:53 +08:00
    你的这两种方案都有一些问题。

    两个方案都没有版本的概念,这样会导致你本次功能上线出现问题后,无法正确回滚至上一版本。方案二不应该在测试后再进行代码合并,测试的永远应该是最后要上线的代码。

    我公司通常这么处理的:

    - 从 master 拉取 release-xxx 作为本次的发布分支
    - 再从发布分支中 release-xxx 拉取开发分支 feature1212
    - 至于你两种方案中纠结的到底是两个人共用一个开发分支,还是各建一个,我的建议:你们就两个人,没有必要增加分支复杂度,直接公用一个开发分支即可,至于开发中遇到冲突,可以通过频繁的 pull/push 来解决
    - 你两种方案中的 dev 分支我认为也没有起到效果,首先测试代码应该和要发布的代码完全一致才有意义,你这里的 dev 分支没有注明检出来源,feature1212 merge 到 dev ,无法保证 feature1212 和 dev 代码一致。正确做法是你应该 feature1212 合并回 release-xxx ,用合并后的发布分支直接测试
    - 测试完成后发布分支 release-xxx 部署线上发布
    - 发布后出现问题,如果要回滚上一版本,那么直接拿上一版本的发布分支(你这里是 master )部署线上;如果要紧急修复,那么从 release-xxx 中检出一个 release-xxx-fix 去重复上面的过程
    caixiangyu17
        5
    caixiangyu17  
       2021-12-01 13:29:58 +08:00   ❤️ 1
    其实 trank base + feature toggle 是个挺方便的,省去各种 checkout ,merge ,rebase ,pr 的时间,只不过很多公司都习惯各种 branch+pr
    我们最近折中了一下,主要是 pr 比较好查看所有的文件变化。基本上流程就是从 master checkout 一个分支,然后每天早上从 master 用 rebase 的方式 pull 到当前 branch 。有冲突就解决,没有更好。最后完成的时候再从 master 拉一下,如果没冲突,建 pr 直接 rebase 回 master 。省时省力,每天解决的冲突,也不至于太多。
    其实只要 pipeline 的测试覆盖率够高,问题一般是不大的。还有就是 pre-push 脚本的检测要尽量和 pipeline 一致,这样可以很高效率解决提交代码之后不去检查 pipeline ,然后还得别人问找提交的人,为啥编译不过了,测试挂了之类的问题
    xz410236056
        6
    xz410236056  
       2021-12-01 14:02:50 +08:00
    @hlwjia #1 拿 2015 年的东西说举例子。。。
    @yl20181003 #2
    @gzf6 #3

    git flow 发明人 Vincent 都说 git flow 不适合持续交付了。。
    MXuD0ng
        7
    MXuD0ng  
       2021-12-01 16:04:08 +08:00
    你这两个方式都是按照人来划分分支的,我觉得可以考虑这样:
    如果是大型 feature 要切成小的 feature ,
    然后一个 feature 一个分支,两个人开发完了小 feature 就合到开发分支(目的是始终保持开发分支拥有全部代码),
    最后测试直接从开发分支切除测试分支(我不太理解为什么要 merge 到测试分支),然后测试通过后封版,推上线。

    如果需要持续交付,你仅需要保证你的开发分支包含了全部代码就不会有问题(比如你为了在部署环境特化配置,但是配置没有同步给开发分支就会有问题,开发分支没有特化配置的提交,所以开发和线上不对等,不可以直接切)
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2846 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 08:36 · PVG 16:36 · LAX 00:36 · JFK 03:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.