V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
zenfsharp
0.1D
0.01D
V2EX  ›  程序员

各位大佬,你们公司内部的代码库有 PR 吗?

  •  
  •   zenfsharp · 8 小时 40 分钟前 · 1515 次点击

    我司一共才四五个后端,现在是各玩各的,各人熟悉自己的一摊逻辑,很少碰其他人的。

    这导致有些底层逻辑明明可以共用同一个函数,也几乎人手一个实现;另外这个人 A 改动的东西,可能也影响了另一个人 B 的逻辑却不知道,导致程序 bug 了,B 寻思着明明我最近没改这块怎么忽然出 bug 了,找半天发现是 A 动了底层,而 A 又不知道 B 也在用这个。

    所以我们老板想在公司内的代码库里开 PR ,自己的分支合并到 Dev 分支时要走 PR ,让另一个人 review 一下,这样能不能提升代码质量另说,起码能增加内部交流。

    各位大佬你们公司内部有 PR 吗?

    20 条回复    2025-12-17 19:38:49 +08:00
    touchwithe
        1
    touchwithe  
       8 小时 39 分钟前 via iPhone
    我们也是一样的,但实际执行中就变成了看也不看直接通过 pr
    zyq2280539
        2
    zyq2280539  
       8 小时 36 分钟前
    大多数都是这样,看都不看,你吆喝一声合并代码,我回复个 Ok ,流程走完了
    labubu
        3
    labubu  
       8 小时 35 分钟前 via Android
    理想很丰满,现实很骨感
    zcf0508
        4
    zcf0508  
       8 小时 33 分钟前 via Android
    我们现在有这个流程,我是会看的,但是其他人很少看,都是直接 a
    ty29022
        5
    ty29022  
       8 小时 33 分钟前
    工作流改不改另说, 难道没有回归
    kakki
        6
    kakki  
       8 小时 21 分钟前
    关键是提升 review 人的权限,建议用 AI 做这个角色最好,不得罪人.
    StrayBugs
        7
    StrayBugs  
       8 小时 2 分钟前
    多人参与的情况下 PR 还是很必要的,但不必原教旨执行。如果一个项目大部分是一个人负责的,那么 ta 可以配置绕过规则,不需要 PR 直接推,但主分支 force push 最好还是禁掉。审核的繁琐问题可以搭配 AI 像 CodeRabbit 效果很好的,能抓很多细微的 bug 。
    InDom
        8
    InDom  
       7 小时 57 分钟前
    我司不仅有 PR Code Review, 还有 Review 检查单, 每次 Code Review 都要填单子.
    Cheez
        9
    Cheez  
    PRO
       7 小时 50 分钟前   ❤️ 1
    给你个最佳实践吧,对于你们这样子的公司,最好就是开 PR ,但是让 PR 的提出者也可以合并,同时设置 CODE OWNER 机制,这个 GitLab 这样子成熟的平台都有,也就是说,只要这个人改的是自己代码范围内的,就无需 REVIEW 。但是改到了别人的代码头上的,就需要 REVIEW 。那么哪怕他再偷懒,至少也会让自己代码放在可控范围内,不会干扰到别人。

    至于说未来可能出现的,一个功能被不同人在他们各自的地方实现一遍的话,就需要更高权限的人或者是更愿意重构的人来推动。
    reoah2
        10
    reoah2  
       7 小时 50 分钟前
    难道你们每个人都直接往 main 上提代码?我们组后端也四五个,但 main 设置保护,不能直接 push ,所有到 main 的都要走个人的 dev 分支提 pr ,虽然不至于每行都看,但改了哪些地方还是要大致看下的,不影响到自己就行
    PythonYXY
        11
    PythonYXY  
       6 小时 23 分钟前
    可以在提 pr 的时候强制要求 ai review 一遍,不过现在 ai 评审也只是看变更部分的代码,不会结合整个仓库来 review
    bghtyu
        12
    bghtyu  
       6 小时 23 分钟前
    也看忙不忙吧,我们每天都开会一起 review 所有的 PR ,review 完了才能 merge 。
    Oilybear
        13
    Oilybear  
       6 小时 19 分钟前
    我感觉你需要不是话时间的 review ,而更像是给 PR 提交后自动触发 pipline 跑一下单元测试,再来谈 preview
    realpg
        14
    realpg  
    PRO
       5 小时 56 分钟前
    @zyq2280539 #2
    我们这边一般改动也是一样 喊一声 先从开发分支流水线构建一下部署到临测环境 然后合并的人简单手动测测 大致没问题就合了

    但是遇到麻烦的大变动 或者影响非常大的, 那是一定交叉的
    alenryuichi
        15
    alenryuichi  
       5 小时 47 分钟前
    pr 后走 git action 自动让 ai review 和修改就好了
    litchinn
        16
    litchinn  
       5 小时 43 分钟前
    这种 review 也不一定看的出来,你不能指望肉眼就看出 bug ,何况很多情况类似 1,2 楼这种,
    所以你需要的是单元测试,保证覆盖率
    SoulFlame
        17
    SoulFlame  
       5 小时 39 分钟前
    代码库没有 PR 也不会有你说的问题吧?
    如果主分支别人合并了最新代码过去,后面的人推送不上去才对啊,他也是要更新代码解决冲突的。
    我们原则就是谁最后推的问题代码谁负责。
    wu00
        18
    wu00  
       5 小时 34 分钟前
    新人的代码,有空会 review 一下
    一是没空,二是大部分人提的 PR 根本没眼看,动不动一个 commit 上千行还不"干净"
    flowerains
        19
    flowerains  
       5 小时 30 分钟前
    一开始初衷都是好的,有个项目负责人天天 R 代码,然后通过 PR 的再上线。
    后来项目负责人忙的跟条狗一样,下面的人又被 deadline 逼着要死要活,想出这招的领导一拍脑袋先过吧。
    然后就没有然后了
    guanzhangzhang
        20
    guanzhangzhang  
       1 小时 28 分钟前
    其实我觉得单元测试也可以搞起来,这样避免后续 review 没问题,合进去炸了。。。
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   3000 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 13:06 · PVG 21:06 · LAX 05:06 · JFK 08:06
    ♥ Do have faith in what you're doing.