V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
jasondennis12139
V2EX  ›  问与答

最近提版本发布,出现大量冲突与代码遗漏,有什么比较好的免这些问题的代码开发流程?

  •  
  •   jasondennis12139 · 2022-04-21 11:05:53 +08:00 · 1971 次点击
    这是一个创建于 791 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我司现在当前的开发流程如下:
    主仓 fork 到个人仓
    个人仓 dev 分支开发,分为 Bug 修复和新功能开发
    -> merge 到 主仓 dev
    -> 脚本 merge 到主仓 test
    -> 脚本 merge 到主仓 release

    存在问题,部分新功能开发周期长达 3 到 4 个月,各个功能之间存在着复杂的相互依赖(比如:开发顺序 AB ,B 动了 A 的部分代码 但是发布顺序 BA 的这种问题)

    想看一下广大 V 友有什么更好更科学的开发流程
    第 1 条附言  ·  2022-04-21 14:18:05 +08:00
    最主要的问题是,3 到 4 个月的开发周期是由于一个重要功能涉及所有的模块和微服务,开发量很大,在未开发完的时候无法提交到测试和发布分支。
    因此定期提交到发布分支是不可能的。而在这个大规模功能未开发完成验证无误之前,其他的 BUG 修复和新功能开发,由于此功能的代码提交到了开发分支,也会依赖于这部分代码。从而造成大范围的冲突。
    22 条回复    2022-04-22 09:57:16 +08:00
    sadfQED2
        1
    sadfQED2  
       2022-04-21 11:19:36 +08:00 via Android
    第一次见到有 fork 到个人仓这种流程😂直接在主仓建 dev 分支有啥问题吗?
    jasondennis12139
        2
    jasondennis12139  
    OP
       2022-04-21 11:21:50 +08:00
    @sadfQED2 在主仓每人都建一个 dev 分支?二三十个个人的 dev 分支很难管理啊
    sadfQED2
        3
    sadfQED2  
       2022-04-21 11:31:13 +08:00 via Android
    @jasondennis12139 为啥难管理,你们要管理啥?我们项目都是上千个分支啊

    主仓库 release 分支是线上代码
    Master 分支是待上线代码
    Test 是测试代码

    这三个分支开启 merge 保护,不能随意合代码进去,其他分支都随便玩
    ccyu220
        4
    ccyu220  
       2022-04-21 11:31:38 +08:00
    @jasondennis12139

    个人认为:公司项目就不需要像 GitHub 上那样先 fork 再分支的流程。

    如同 1# 说的一样,每个功能在主仓建立一个分支,开发根据需求再自己本地分支就好了。

    如果有公共文件修改,那就再分支一个需求,merge 之后各人再拉取。

    dev 全部开发合并完成之后主分支再按版本合并。

    ---

    综上,不知是否有我还未认知的利弊?我也想学习下其他人的流程是如何。
    sadfQED2
        5
    sadfQED2  
       2022-04-21 11:32:02 +08:00 via Android
    我们是主仓每个需求建一个分支
    MoYi123
        6
    MoYi123  
       2022-04-21 11:32:52 +08:00
    @jasondennis12139 分支肯定不是按人建, 而是按功能建啊.
    Jooooooooo
        7
    Jooooooooo  
       2022-04-21 11:51:53 +08:00
    组内互相了解大家的需求大致的改动啊, 如果有改动同一处功能得提前沟通.

    不过你们啥东西需要开发 3 个月? 拆小分开上呗.
    starerlloll
        8
    starerlloll  
       2022-04-21 11:53:05 +08:00   ❤️ 1
    我觉得主要问题是 3-4 个月才合并一次代码。。这频率太低了。。。还有 20 多个开发,,
    GeruzoniAnsasu
        9
    GeruzoniAnsasu  
       2022-04-21 11:56:16 +08:00
    PLEASE (大写强调) 最长周期 一周

    合一次代码



    开发周期和代码同步周期完全是两回事,代码同步频率拉起来你遇到的依赖问题全都不存在了


    啊,你说没写完同步代码没意义,所以为什么不把任务拆细一点每个可以跑的单元都尽可能小呢,这不就「敏捷」起来了
    securityCoding
        10
    securityCoding  
       2022-04-21 12:04:42 +08:00 via Android
    @sadfQED2 大仓模式下都在主库搞分支不现实的。
    laozhoubuluo
        11
    laozhoubuluo  
       2022-04-21 12:14:45 +08:00   ❤️ 2
    1. 一个开发团队开发一个新功能开发周期 3 - 4 个月说明软件架构有严重问题,绝大多数项目和公司根本接受不了这个周期。建议需求规划端做合理拆分,单个需求用 4 个月不如拆成 20 个需求每个一周会更合理。如果没法拆分那也没办法,说明软件架构积重难返了,如果您不是给金融行业写 COBOL 的工作建议尽快转行。
    2. 如果确实积重难返的话也有办法缓解,如果一个需求 7 天之内做不完,那么每周需要找一天 rebase 每个需求的 dev 仓库,保证当时 dev 仓库的内容是主线 Dev 仓库 + 新增内容,可以保证合并期间不那么折腾,相当于牺牲开发进度保证最后合并成功率。
    wd
        12
    wd  
       2022-04-21 12:17:48 +08:00 via iPhone   ❤️ 1
    你需要的恐怕是多花点钱雇几个靠谱的人...
    zpxshl
        13
    zpxshl  
       2022-04-21 13:04:19 +08:00 via Android
    我们主仓几万条分支,还有大量子仓,同样分支爆炸
    FranzKafka95
        14
    FranzKafka95  
       2022-04-21 13:09:26 +08:00 via Android
    功能开发三四个月不代表你三四个月提交一次吧,更新一点就提交到远程主仓,其他同事及时更新后 merge 到本地个人分支,大家都这样操作就行了
    Building
        15
    Building  
       2022-04-21 13:13:03 +08:00
    这就是为什么项目同一个功能的函数能出现好几个的原因,为了方便都手写了一个 private 的给自己专用
    cutepig
        16
    cutepig  
       2022-04-21 13:34:11 +08:00 via Android
    我们这边有类似的问题,我们总结原因在于软件设计不好。模块化做的不好。code review 不够。代码修改太随意。
    我们正在通过 pull request 做 code review ,希望能够改善情况
    仅供参考
    jasondennis12139
        17
    jasondennis12139  
    OP
       2022-04-21 14:26:38 +08:00
    @starerlloll 肯定不是 3 个月才合一次,是一个很大的新增需求,覆盖了几乎所有模块,并且直接催生了一个新的微服务。期间不停的在向开发分支提交代码,也定期 merge 到测试分支。但是在大范围提发布到发布分支的时候出了问题。
    mozhizhu
        18
    mozhizhu  
       2022-04-21 14:28:49 +08:00
    AB 相互依赖部分抽离出来,做 Base ,每次变化都基于 Base 修改(开发阶段支持 A 、B 单独调用),Base 及时进行测试和内部发布;尽量不要因为 AB 同改,最后合并爆炸
    Huozy
        19
    Huozy  
       2022-04-21 19:37:38 +08:00   ❤️ 1
    不建议 fork 到个人仓。

    假定 Master 分支为生产版本代码,测试环境分支 test ,验证环境分支 UAT 。生产发布周期为 7 天一次。
    Master 、UAT 、test 分支均受保护,普通开发无法直接提交或合并。

    需求 A 从 Master 分支切出一个 dev_A ,需求 B 从 Master 切出 dev_B ,dev*分支都是由开发个人维护的,做相应需求开发。
    dev*分支在开发过程中应在每个上线周期后与 mater 进行同步。
    开发完成后,发起合并请求至 test ,上测试。由专人进行合并管理解决冲突。

    假定上线日为 T 日,那么在 T-7 日时,应将已经测试完成的 dev_A ,由专人合并至 UAT 分支,发布进行验证测试。完成后将 UAT T-7 日版本 打包进入待上线,T 日发布。

    发布成功后,T+1 日将 UAT 分支合并至 Master 分支,并打上 tag 。
    假设 T+2 日,发现重大 BUG ,应从 Master 分支切出 BugFix 分支修复,并直接合并至 UAT 分支进行测试验证再发布。

    理论上来说,test 分支上的 feature 功能不会与 UAT 同步,即某些功能上了测试,但可能最终都不会正式发布,那么此时 test 分支已经与 Master/UAT 相差较远,所以 test 分支应该定期删除,重新从 Master 分支切出,再将 dev*合入 test 分支进行测试。

    上了 UAT 分支的代码,一定是要发布至生产的,如不发布,需要回退 UAT 分支。

    如果你的 A 需求与其他需求代码出现大量冲突或者大量依赖的,需要团队负责人对开发周期进行考量和调整。
    git 工作流没有办法完全解决代码冲突,只是尽可能的减少冲突出现。
    dlsflh
        20
    dlsflh  
       2022-04-21 21:48:52 +08:00
    大家好,请问楼上这些知识看什么书能获得?
    duke807
        21
    duke807  
       2022-04-22 01:59:42 +08:00 via Android
    建議用 gerrit ,不需要 fork 到個人倉,主庫也不會分支爆炸,多人研發同步進度也及時
    Bluelion
        22
    Bluelion  
       2022-04-22 09:57:16 +08:00
    @dlsflh 去一家用 git 管理代码的公司上两个月班就获得了,或者自己看 git 的资料,搭个仓库自建项目和分支操作下
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5346 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 03:33 · PVG 11:33 · LAX 20:33 · JFK 23:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.