作者SuKamo (小书僮)
看板Soft_Job
标题[讨论] 不发 PR 的公司会很怪吗
时间Fri Aug 16 12:53:01 2024
今年年初我朋友面试进到一间港商，是一家电商小公司，最近跟他吃饭在聊公司的开发流
程
聊着聊着，竟然发现他们有使用 Github 但却没有发 PR
流程大概就是
切 branch -> 开发 -> 做完丢 branch name 给上头 review
我一听就觉得超怪，我朋友一开始进去也有问其他同事，但他们就是一脸很正常的样子，
他之後也习以为常了
有用 Github 但不发 PR 的公司真的是第一次听到...
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 106.64.184.20 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1723783983.A.146.html
1F：→ sisdad: 有没有一种可能是你见过的世面太少08/16 13:06
2F：→ surfingbboy: 不会08/16 13:11
4F：→ stepnight: 就是用不用这功能而已，做得也没哪里不一样08/16 13:15
5F：→ stepnight: 还是你觉得用什麽需求一定要用到PR才能做到08/16 13:15
比如说可以直接在你的 code 上去做评论
没用的话就会变成是「在 xx function 内的某个 function...」，沟通起来就会没那麽
直观
6F：→ Newtype: 至少有review了08/16 13:15
7F：推 t19960804: 是觉得有发pr比较正式吧08/16 13:18
8F：→ qoo1991: Linus 也没用PR 该怎麽办08/16 13:20
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 13:25:57
9F：推 mercurycgt68: trunk based development:08/16 13:26
我们公司就是用 trunk based，每次 merge 回主线就是发 PR
10F：→ bear1414: 方法(any)是灵活的 本质(review)才是重要的08/16 13:27
11F：推 abc0922001: 肯定有段故事的08/16 13:29
12F：推 Imin0905: 有review就不错了吧…08/16 13:32
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 13:34:12
13F：推 feathergod: 至少有review 前公司不review还会在production branc08/16 13:35
14F：→ feathergod: h开发08/16 13:35
15F：嘘 MoonCode: 没有特别说明为何这样做的话 就是雷08/16 13:37
16F：推 NDark: PR只是一种merge的备忘录，只要事情没有多到记不住。merge 08/16 13:38
17F：→ NDark: 也可以达到相同功能。当然搭配自动测试这是两件事。 08/16 13:38
18F：推 lwecloud: 小公司有啥好意外 功能做出来卖钱才是重点 08/16 13:40
19F：推 NDark: 这就像是一人开发要不要用issue tracking 08/16 13:49
20F：→ Obama19: 发pr有法律规定吗？ 08/16 13:50
21F：→ NDark: 如果事情没有多到记不住自己不用装模作样开issue给自己 08/16 13:50
我比较疑惑的点是明明有 PR 这个功能可以方便 code review，反而要用其他绕路的方式
来进行，觉得很奇怪
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 13:51:49
22F：推 NDark: 对於更直接当面讨论的团队来说，说不定PR才是绕路。 08/16 13:52
23F：→ answermangtr: 只是流程不一样而已 还是有review 08/16 13:54
但有发 PR 这流程会让 review 变得轻松点
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 13:57:05
24F：→ shooter555: 没有review就不用PR MR啦 08/16 14:02
25F：→ nh60211as: 但有发 PR 这流程会让 review 变得轻松点 => 不一定08/16 14:03
26F：推 NDark: 同楼上 08/16 14:09
27F：推 abccbaandy: 有真review就屌打大部分公司了... 08/16 14:36
28F：→ ssccg: 看起来只是你习惯用github的UI而已 08/16 14:47
29F：→ bheegrl: 大家有默契就好了08/16 15:04
30F：推 chopinmozart: Real man test on production 08/16 15:40
31F：→ luke72: 团队才几个人发PR是能多赚钱吗？repo搞不好是单人开发 08/16 15:48
32F：→ luke72: 一堆新手看了广告文，就想拿5000人团队制度套到5人团队 08/16 15:50
33F：→ zxc8787: git的具体使用流程应该是配合公司吧 08/16 15:56
34F：→ zxc8787: 有pr就有pr，没有也不会怎样吧 08/16 15:56
35F：推 abc0922001: 有可能刚学会怎麽用git，没时间也没心力测试这个流程 08/16 16:16
36F：推 wei115: pr是github的功能吧？如果只是把github当git server没pr 08/16 16:25
37F：→ wei115: 也ok 08/16 16:25
38F：推 jackflu: 我觉得上面部份人其实不懂 PR，所以看不懂你的纳闷，哈哈 08/16 16:36
39F：推 happy8649: 我看完留言想法也跟楼上一样 08/16 16:38
40F：→ alan3100: pr都不懂别想说git flow自己管是多会管理拉..08/16 17:43
41F：推 iamOsaka: 小团队还好吧 如果一个repo有上百个人在开发哪可能非08/16 17:47
42F：→ iamOsaka: 用不行 08/16 17:47
43F：→ moom50302: 内文加留言 满满的工程师相轻 08/16 18:00
44F：→ henrylin8086: 有可能是在Review完由Reviewer Merge，那不一定要M08/16 18:44
45F：→ henrylin8086: R, PR08/16 18:44
46F：推 crazwade: 公司就是 有分不同分支开发最後由主开发人来merge 不懂 08/16 19:05
47F：→ crazwade: 为什麽不用 PR就好08/16 19:05
48F：嘘 hegemon: 总比要大家全部都直接上main好吧 08/16 19:05
49F：→ newbout: 看公司吧，我之前公司是小接案公司，功能在 dev branch 08/16 19:30
50F：→ newbout: 上没什麽问题就给客户看了 08/16 19:30
51F：推 TSMCfabXX: 一人开发 没有大家08/16 19:38
我认知中，发 PR 并不会有多高的成本，发完後 review 没问题一键 merge，讨论也可以
直接针对 code 来看，还能留个记录在上面
不然就要一个一个 commit 看，看完後 DM or 公频(slack, jira)留 comment 给开发者
，还没办法直接对照是哪段 code 被 comment
过了之後还要在 terminal 执行 merge 再推上去
我比较下来发 PR 就是个没坏处且好处多多的流程
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 20:09:23
52F：推 wulouise: github pr不适合per commit review 08/16 20:10
53F：→ wulouise: 但是交流还是方便很多没错啦 08/16 20:10
没吧，你一个 PR 还是可以包很多 commit 进来一起 review 呀
※ 编辑: SuKamo (114.27.35.104 台湾), 08/16/2024 20:14:12
54F：→ Ekmund: 就风格不同吧 我遇过不同team 有的会发 有的直上的公司 08/16 20:20
55F：→ Ekmund: 也遇过流程上会先後经过design review、code review 08/16 20:20
56F：→ Ekmund: 这我就觉得发不发都还好 08/16 20:20
57F：→ Ekmund: 当然完全不管的 应该连讨论都不用啦 08/16 20:21
58F：→ MoonCode: 不用 pr 就怕人工合并的时候被加料 去跟谁解释 这资安 08/16 20:33
59F：→ MoonCode: 扣分吧 08/16 20:33
60F：→ dog30111: 是我的话会站出来推动这件事，是个展现软实力的机会 08/16 20:39
61F：推 wd122344556: 是不是南京复兴附近那间哈哈哈哈 08/16 20:46
62F：→ DrTech: 重点是程式码品质有在管。而不是各种花俏，形式化的流程。 08/16 20:50
63F：→ DrTech: 程式码品质，有在管PR可有可无。程式码品质没在管，再多re 08/16 20:50
64F：→ DrTech: view与流程，再多PR都没用。 08/16 20:50
65F：→ luke72: 留comment给开发者，嗯，很多公司开发者就是你自己啊 08/16 21:45
66F：→ luke72: 就算是上市大公司，常常功能切很细，repo还是只有你在做 08/16 21:46
67F：→ luke72: 跨部门合作的repo发PR，但一人两人的何必拘泥於这个 08/16 21:49
68F：→ peter98: 不会 08/16 21:50
69F：→ luke72: 我也见过一人repo走git flow，merge还要两人签核才能过 08/16 21:51
70F：→ luke72: 然後某天半夜出bug要紧急修复，找不到人签核…. 08/16 21:51
71F：→ luke72: 只好动用admin权限先砍了他的policy再说 08/16 21:52
72F：→ peter98: 楼上luke说的就是标准的系统烂、没做好，Code review系统 08/16 22:13
73F：→ peter98: 应该要有个override & merge 08/16 22:13
74F：→ netburst: 没用ftp就万幸了 08/16 22:56
75F：→ luke72: Code review & QA只是降低错误发生，不是免疫啦 08/17 00:01
76F：→ luke72: 意外就是过去从未想过的状况，能看出的就不是意外了 08/17 00:04
77F：→ luke72: 一个team两三个人，有几十个小repo很常见吧 08/17 00:06
78F：→ luke72: 我想讲的就只是，大型repo的管理方法，并不是小型也适用 08/17 00:07
79F：推 wulouise: github pr预设你一次全看，一条条看commit很麻烦..不过 08/17 00:17
80F：→ wulouise: 这就是设计理念不同的差异，至少还能多条看就很好了 08/17 00:17
81F：→ alan3100: 脱裤子放屁而已 PR跟反对理由根本不冲突 单纯不会用 08/17 00:58
82F：→ alan3100: 会觉得卡通常就只是把git当备份机制 习惯想怎麽改就怎麽 08/17 01:03
83F：→ alan3100: 改 垃圾进main後又跟部属环境不一致 随时想魔改rollback 08/17 01:05
84F：推 happy8649: 一条一条看不是就按next commit就好了吗=_=麻烦在哪 08/17 01:17
85F：嘘 a731977: 不会 08/17 01:54
86F：→ angusyu: 下篇文章：为什麽不用Github 08/17 02:30
87F：→ acgotaku: 就没 peer 可以 review 呀 我自己做自己的专案也懒得发 08/17 05:01
88F：推 poison5566: 规模太小的团队就容易没有吧 08/17 05:45
89F：推 Firemaples: 遇过不 review，开发不切 branch，全靠人力 QA 管品 08/17 08:26
90F：→ Firemaples: 质的公司 08/17 08:26
91F：→ Firemaples: 有 review 已经很不错了 08/17 08:26
92F：推 qazwsx12: 我觉得质疑的也很怪..有这功能为啥不用，没有缺点都是 08/17 10:24
93F：→ qazwsx12: 优点啊！ 08/17 10:24
94F：推 wulouise: 他一条render一次没办法快速切吧，有办法设定请告诉我.. 08/17 13:11
95F：推 geoege022702: ㄤㄧ 08/17 14:32
96F：推 Arbin: 还在用SVN的公司： 08/17 15:36
97F：推 yamagishi: 原PO是在说优点那麽多又没甚麽麻烦怎麽不用PR 08/17 15:49
98F：推 Phenomenon: 有 review 就赢了，多的是开 PR 直接 approve 08/17 18:00
99F：嘘 B0988698088: 你可以直接跟对方讨论优缺点 回来这里优越发一篇是 08/17 18:36
100F：→ B0988698088: 要干嘛 08/17 18:36
101F：→ qpowjohn: 我的感觉就是早期用SVN，後来转移到git的公司 08/17 19:07
102F：推 pot1234: gerrit好像没用pr 08/17 21:46
103F：→ LiebeLion: 有commit就能review啊 08/17 21:56
104F：→ LiebeLion: 在branch code一样可以留comment 08/17 21:56
105F：推 qrtt1: 有 PR 才好接自动测试或是相关的 workflow 08/17 22:55
106F：→ iamshiao: 既然都要 review 了，用 PR 比较方便吧 08/17 23:55
107F：推 luappc: 待过使用TFS+Git的公司，走Git flow，每个同事分支权限开 08/18 18:04
108F：→ luappc: 到最大，通常都自己直接Merge develop给QA测试，根本没人 08/18 18:04
109F：→ luappc: 用过TFS内建的PR功能，出问题再用git blame查是被谁改的 08/18 18:04
110F：→ notimenofree: 你可以问主管啊问我们怎麽知道 08/19 05:59
111F：推 smch: 有review就不错了 08/19 08:36
112F：→ bean90638: 前公司没在review 用SVN 没在开分支全部人往主线传QQ 08/19 09:06
113F：推 MonkeyCL: 真的 有review就不错了 08/19 11:01
114F：推 lin70208: 你问一下主管就知道了阿... 08/19 12:47
115F：推 Hitmear: 听起来是svn workflow，这就习惯而已又没对错 08/19 13:21
116F：→ becca945: 没拿usb传给你不错了 08/19 21:24
117F：→ lovebridget: 小公司还在给你玩官僚那套那早倒了 08/19 22:37
118F：→ lovebridget: 没事找事做是大公司赚钱後没事干的特权 08/19 22:37
119F：→ ashlikewing: 有了PR比较好review 是什麽概念 08/20 20:49
120F：推 NDark: 部分的工程师偏好用文字沟通 也许一来一往比较有生产力 08/20 21:00
121F：推 Hwangloveyu: 又是看了几本书开始检讨别人吗？ 08/23 19:59
122F：→ mm58307533: 一堆根本不review的公司也发PR 08/24 19:17
123F：→ knives: 重要的是把事情做好 08/25 16:56
124F：→ MonyemLi: 各种公司都有，看你可否接受 08/28 18:46