首页注册登录

V2EX = way to explore V2EX 是一个关于分享和探索的地方

现在注册已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

zenfsharp

0.01D

V2EX › 程序员

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

zenfsharp · 2025 年 12 月 17 日 · 2894 次点击

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

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

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

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

第 1 条附言 · 2025 年 12 月 18 日

感谢各位大佬提供经验和支招🙏
我们倒是有自动化测试,PR 主要是为了让程序员之间加强沟通,现在他们各自为营,每人手里几个开发任务,多任务并行,每个任务只由一个人开发,几乎 0 合作。
老板想让大家知道别人写了什么,别重复造轮子。
既然这样,就弄吧。下限是闭眼直接通过 PR ,跟现在直接合并分支一样,没什么坏处。能缓解老板焦虑,他开心就好。

PR 代码库 Review

23 条回复 • 2025年12月18日 17:21:15 +08:00

touchwithe

touchwithe 2025 年 12 月 17 日 via iPhone

我们也是一样的,但实际执行中就变成了看也不看直接通过 pr

zyq2280539

zyq2280539 2025 年 12 月 17 日

大多数都是这样,看都不看,你吆喝一声合并代码,我回复个 Ok ,流程走完了

labubu

labubu 2025 年 12 月 17 日 via Android

理想很丰满,现实很骨感

zcf0508

zcf0508 2025 年 12 月 17 日 via Android

我们现在有这个流程,我是会看的,但是其他人很少看,都是直接 a

ty29022

ty29022 2025 年 12 月 17 日

工作流改不改另说, 难道没有回归

kakki

kakki 2025 年 12 月 17 日 ❤️ 1

关键是提升 review 人的权限,建议用 AI 做这个角色最好,不得罪人.

StrayBugs

StrayBugs 2025 年 12 月 17 日 ❤️ 1

多人参与的情况下 PR 还是很必要的,但不必原教旨执行。如果一个项目大部分是一个人负责的,那么 ta 可以配置绕过规则,不需要 PR 直接推,但主分支 force push 最好还是禁掉。审核的繁琐问题可以搭配 AI 像 CodeRabbit 效果很好的,能抓很多细微的 bug 。

InDom

InDom 2025 年 12 月 17 日

我司不仅有 PR Code Review, 还有 Review 检查单, 每次 Code Review 都要填单子.

Cheez

Cheez

PRO

2025 年 12 月 17 日 ❤️ 2

给你个最佳实践吧,对于你们这样子的公司,最好就是开 PR ,但是让 PR 的提出者也可以合并,同时设置 CODE OWNER 机制,这个 GitLab 这样子成熟的平台都有,也就是说,只要这个人改的是自己代码范围内的,就无需 REVIEW 。但是改到了别人的代码头上的,就需要 REVIEW 。那么哪怕他再偷懒,至少也会让自己代码放在可控范围内,不会干扰到别人。

至于说未来可能出现的,一个功能被不同人在他们各自的地方实现一遍的话,就需要更高权限的人或者是更愿意重构的人来推动。

reoah2

reoah2 2025 年 12 月 17 日

难道你们每个人都直接往 main 上提代码?我们组后端也四五个,但 main 设置保护,不能直接 push ,所有到 main 的都要走个人的 dev 分支提 pr ,虽然不至于每行都看,但改了哪些地方还是要大致看下的,不影响到自己就行

PythonYXY

PythonYXY 2025 年 12 月 17 日

可以在提 pr 的时候强制要求 ai review 一遍,不过现在 ai 评审也只是看变更部分的代码,不会结合整个仓库来 review

bghtyu

bghtyu 2025 年 12 月 17 日

也看忙不忙吧,我们每天都开会一起 review 所有的 PR ,review 完了才能 merge 。

Oilybear

Oilybear 2025 年 12 月 17 日 ❤️ 1

我感觉你需要不是话时间的 review ,而更像是给 PR 提交后自动触发 pipline 跑一下单元测试,再来谈 preview

realpg

realpg

PRO

2025 年 12 月 17 日

@zyq2280539 #2
我们这边一般改动也是一样喊一声先从开发分支流水线构建一下部署到临测环境然后合并的人简单手动测测大致没问题就合了

但是遇到麻烦的大变动或者影响非常大的, 那是一定交叉的

alenryuichi

alenryuichi 2025 年 12 月 17 日 ❤️ 1

pr 后走 git action 自动让 ai review 和修改就好了

litchinn

litchinn 2025 年 12 月 17 日 ❤️ 1

这种 review 也不一定看的出来,你不能指望肉眼就看出 bug ,何况很多情况类似 1,2 楼这种,
所以你需要的是单元测试,保证覆盖率

SoulFlame

SoulFlame 2025 年 12 月 17 日

代码库没有 PR 也不会有你说的问题吧?
如果主分支别人合并了最新代码过去,后面的人推送不上去才对啊,他也是要更新代码解决冲突的。
我们原则就是谁最后推的问题代码谁负责。

wu00

wu00 2025 年 12 月 17 日

新人的代码,有空会 review 一下
一是没空,二是大部分人提的 PR 根本没眼看,动不动一个 commit 上千行还不"干净"

flowerains

flowerains 2025 年 12 月 17 日

一开始初衷都是好的,有个项目负责人天天 R 代码,然后通过 PR 的再上线。
后来项目负责人忙的跟条狗一样,下面的人又被 deadline 逼着要死要活,想出这招的领导一拍脑袋先过吧。
然后就没有然后了

guanzhangzhang

guanzhangzhang 2025 年 12 月 17 日

其实我觉得单元测试也可以搞起来,这样避免后续 review 没问题,合进去炸了。。。

unco020511

unco020511 2025 年 12 月 18 日

有啊,每次功能完成合入主干会有几个同学去审核

tsvico

tsvico 2025 年 12 月 18 日

我们是严格审核 pr ,代码也有 format 校验

JohnnyBoy

JohnnyBoy 2025 年 12 月 18 日

合就合呗, 后面跟着的就是 ci test, 谁搞失败了谁修

关于 · 帮助文档 · 自助推广系统 · 博客 · API · FAQ · Solana · 2770 人在线 最高记录 6679 · Select Language 创意工作者们的社区 World is powered by solitude VERSION: 3.9.8.5 · 29ms · UTC 14:28 · PVG 22:28 · LAX 06:28 · JFK 09:28
♥ Do have faith in what you're doing.