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