这是一个创建于 128 天前的主题，其中的信息可能已经有所发展或是发生改变。
我司一共才四五个后端，现在是各玩各的，各人熟悉自己的一摊逻辑，很少碰其他人的。
这导致有些底层逻辑明明可以共用同一个函数，也几乎人手一个实现；另外这个人 A 改动的东西，可能也影响了另一个人 B 的逻辑却不知道，导致程序 bug 了，B 寻思着明明我最近没改这块怎么忽然出 bug 了，找半天发现是 A 动了底层，而 A 又不知道 B 也在用这个。
所以我们老板想在公司内的代码库里开 PR ，自己的分支合并到 Dev 分支时要走 PR ，让另一个人 review 一下，这样能不能提升代码质量另说，起码能增加内部交流。
各位大佬你们公司内部有 PR 吗？
第 1 条附言 2025 年 12 月 18 日
感谢各位大佬提供经验和支招
我们倒是有自动化测试，PR 主要是为了让程序员之间加强沟通，现在他们各自为营，每人手里几个开发任务，多任务并行，每个任务只由一个人开发，几乎 0 合作。
老板想让大家知道别人写了什么，别重复造轮子。
既然这样，就弄吧。下限是闭眼直接通过 PR ，跟现在直接合并分支一样，没什么坏处。能缓解老板焦虑，他开心就好。
我们倒是有自动化测试，PR 主要是为了让程序员之间加强沟通，现在他们各自为营，每人手里几个开发任务，多任务并行，每个任务只由一个人开发，几乎 0 合作。
老板想让大家知道别人写了什么，别重复造轮子。
既然这样，就弄吧。下限是闭眼直接通过 PR ，跟现在直接合并分支一样，没什么坏处。能缓解老板焦虑，他开心就好。
 | 1 touchwithe 2025 年 12 月 17 日 via iPhone 我们也是一样的，但实际执行中就变成了看也不看直接通过 pr |
 | 2 zyq2280539 2025 年 12 月 17 日 大多数都是这样，看都不看，你吆喝一声合并代码，我回复个 Ok ,流程走完了 |
 | 3 labubu 2025 年 12 月 17 日 via Android 理想很丰满，现实很骨感 |
 | 4 zcf0508 2025 年 12 月 17 日 via Android 我们现在有这个流程，我是会看的，但是其他人很少看，都是直接 a |
 | 5 ty29022 2025 年 12 月 17 日 工作流改不改另说， 难道没有回归 |
 | 6 kakki 2025 年 12 月 17 日  1 关键是提升 review 人的权限,建议用 AI 做这个角色最好,不得罪人. |
 | 7 StrayBugs 2025 年 12 月 17 日 1 多人参与的情况下 PR 还是很必要的，但不必原教旨执行。如果一个项目大部分是一个人负责的，那么 ta 可以配置绕过规则，不需要 PR 直接推，但主分支 force push 最好还是禁掉。审核的繁琐问题可以搭配 AI 像 CodeRabbit 效果很好的，能抓很多细微的 bug 。 |
 | 8 InDom 2025 年 12 月 17 日 我司不仅有 PR Code Review, 还有 Review 检查单, 每次 Code Review 都要填单子. |
 | 9 Cheez PRO 2 给你个最佳实践吧，对于你们这样子的公司，最好就是开 PR ，但是让 PR 的提出者也可以合并，同时设置 CODE OWNER 机制，这个 GitLab 这样子成熟的平台都有，也就是说，只要这个人改的是自己代码范围内的，就无需 REVIEW 。但是改到了别人的代码头上的，就需要 REVIEW 。那么哪怕他再偷懒，至少也会让自己代码放在可控范围内，不会干扰到别人。 至于说未来可能出现的，一个功能被不同人在他们各自的地方实现一遍的话，就需要更高权限的人或者是更愿意重构的人来推动。 |
 | 10 reoah2 2025 年 12 月 17 日 难道你们每个人都直接往 main 上提代码？我们组后端也四五个，但 main 设置保护，不能直接 push ，所有到 main 的都要走个人的 dev 分支提 pr ，虽然不至于每行都看，但改了哪些地方还是要大致看下的，不影响到自己就行 |
11 PythonYXY 2025 年 12 月 17 日 可以在提 pr 的时候强制要求 ai review 一遍，不过现在 ai 评审也只是看变更部分的代码，不会结合整个仓库来 review |
 | 12 bghtyu 2025 年 12 月 17 日 也看忙不忙吧，我们每天都开会一起 review 所有的 PR ，review 完了才能 merge 。 |
 | 13 Oilybear 2025 年 12 月 17 日 1 我感觉你需要不是话时间的 review ，而更像是给 PR 提交后自动触发 pipline 跑一下单元测试，再来谈 preview |
 | 14 realpg PRO @zyq2280539 #2 我们这边一般改动也是一样 喊一声 先从开发分支流水线构建一下部署到临测环境 然后合并的人简单手动测测 大致没问题就合了 但是遇到麻烦的大变动 或者影响非常大的, 那是一定交叉的 |
 | 15 alenryuichi 2025 年 12 月 17 日 1 pr 后走 git action 自动让 ai review 和修改就好了 |
 | 16 litchinn 2025 年 12 月 17 日 1 这种 review 也不一定看的出来，你不能指望肉眼就看出 bug ，何况很多情况类似 1,2 楼这种， 所以你需要的是单元测试，保证覆盖率 |
 | 17 SoulFlame 2025 年 12 月 17 日 代码库没有 PR 也不会有你说的问题吧？ 如果主分支别人合并了最新代码过去，后面的人推送不上去才对啊，他也是要更新代码解决冲突的。 我们原则就是谁最后推的问题代码谁负责。 |
 | 18 wu00 2025 年 12 月 17 日 新人的代码,有空会 review 一下 一是没空，二是大部分人提的 PR 根本没眼看，动不动一个 commit 上千行还不"干净" |
 | 19 flowerains 2025 年 12 月 17 日 一开始初衷都是好的，有个项目负责人天天 R 代码，然后通过 PR 的再上线。 后来项目负责人忙的跟条狗一样，下面的人又被 deadline 逼着要死要活，想出这招的领导一拍脑袋先过吧。 然后就没有然后了 |
 | 20 guanzhangzhang 2025 年 12 月 17 日 其实我觉得单元测试也可以搞起来，这样避免后续 review 没问题，合进去炸了。。。 |
 | 21 unco020511 2025 年 12 月 18 日 有啊,每次功能完成合入主干会有几个同学去审核 |
 | 22 tsvico 2025 年 12 月 18 日 我们是严格审核 pr ，代码也有 format 校验 |
 | 23 JohnnyBoy 2025 年 12 月 18 日 合就合呗, 后面跟着的就是 ci test, 谁搞失败了谁修 |
Select Language