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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

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

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

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

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

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

代码库

Review

19 条回复 2025-12-17 15:36:44 +08:00

touchwithe

6 小时 39 分钟前 via iPhone

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

zyq2280539

6 小时 36 分钟前

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

labubu

6 小时 35 分钟前 via Android

理想很丰满，现实很骨感

zcf0508

6 小时 34 分钟前 via Android

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

ty29022

6 小时 33 分钟前

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

kakki

6 小时 22 分钟前

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

StrayBugs

6 小时 3 分钟前

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

InDom

5 小时 58 分钟前

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

Cheez

PRO

5 小时 51 分钟前

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

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