楼主:
SuKamo (Su_Kamo)
2024-08-16 12:53:01今年年初我朋友面试进到一间港商，是一家电商小公司，最近跟他吃饭在聊公司的开发流
程
聊著聊著，竟然发现他们有使用 Github 但却没有发 PR
流程大概就是
切 branch -> 开发 -> 做完丢 branch name 给上头 review
我一听就觉得超怪，我朋友一开始进去也有问其他同事，但他们就是一脸很正常的样子，
他之后也习以为常了
有用 Github 但不发 PR 的公司真的是第一次听到...
作者: sisdad (sisdad) 2024-08-16 13:06:00
有没有一种可能是你见过的世面太少
就是用不用这功能而已，做得也没哪里不一样还是你觉得用什么需求一定要用到PR才能做到
作者:
Newtype (你快乐所以我快乐)
2024-08-16 13:15:00至少有review了
作者:
qoo1991 (笨哲)
2024-08-16 13:20:00Linus 也没用PR 该怎么办
作者: mercurycgt68 (发芽的吉它手) 2024-08-16 13:26:00
trunk based development:
作者: bear1414 (story) 2024-08-16 13:27:00
方法(any)是灵活的 本质(review)才是重要的
作者:
Imin0905 (Imin0905)
2024-08-16 13:32:00有review就不错了吧…
至少有review 前公司不review还会在production branch开发
作者:
MoonCode (MoonCode)
2024-08-16 13:37:00没有特别说明为何这样做的话 就是雷
作者:
NDark (溺于黑暗)
2024-08-16 13:38:00PR只是一种merge的备忘录，只要事情没有多到记不住。merge也可以达到相同功能。当然搭配自动测试这是两件事。
作者:
lwecloud (CloudEX)
2024-08-16 13:40:00小公司有啥好意外 功能做出来卖钱才是重点
作者:
NDark (溺于黑暗)
2024-08-16 13:49:00这就像是一人开发要不要用issue tracking
作者:
Obama19 (^_^)
2024-08-16 13:50:00发pr有法律规定吗？
作者:
NDark (溺于黑暗)
2024-08-16 13:50:00如果事情没有多到记不住自己不用装模作样开issue给自己对于更直接当面讨论的团队来说，说不定PR才是绕路。
但有发 PR 这流程会让 review 变得轻松点 => 不一定
作者:
NDark (溺于黑暗)
2024-08-16 14:09:00同楼上
作者:
ssccg (23)
2024-08-16 14:47:00看起来只是你习惯用github的UI而已
Real man test on production
作者:
luke72 (ccc)
2024-08-16 15:48:00团队才几个人发PR是能多赚钱吗？repo搞不好是单人开发一堆新手看了广告文，就想拿5000人团队制度套到5人团队
作者:
zxc8787 (摸斗哈压库)
2024-08-16 15:56:00git的具体使用流程应该是配合公司吧有pr就有pr，没有也不会怎样吧
有可能刚学会怎么用git，没时间也没心力测试这个流程
作者:
wei115 (ㄎㄎ)
2024-08-16 16:25:00pr是github的功能吧？如果只是把github当git server没pr也ok
作者:
jackflu (jackflu)
2024-08-16 16:36:00我觉得上面部份人其实不懂 PR，所以看不懂你的纳闷，哈哈
pr都不懂别想说git flow自己管是多会管理拉..
小团队还好吧 如果一个repo有上百个人在开发哪可能非用不行
作者: moom50302 (武林三羚鳄) 2024-08-16 18:00:00
内文加留言 满满的工程师相轻
有可能是在Review完由Reviewer Merge，那不一定要MR, PR
作者:
crazwade (crazwade)
2024-08-16 19:05:00公司就是 有分不同分支开发最后由主开发人来merge 不懂为什么不用 PR就好
作者:
hegemon (hegemon)
2024-08-16 19:05:00总比要大家全部都直接上main好吧
作者:
newbout ( nb 但没有 a )
2024-08-16 19:30:00看公司吧，我之前公司是小接案公司，功能在 dev branch上没什么问题就给客户看了
作者:
wulouise (在线上!=在电脑前)
2024-08-16 20:10:00github pr不适合per commit review但是交流还是方便很多没错啦
作者:
Ekmund (是一只小叔)
2024-08-16 20:20:00就风格不同吧 我遇过不同team 有的会发 有的直上的公司也遇过流程上会先后经过design review、code review这我就觉得发不发都还好当然完全不管的 应该连讨论都不用啦
作者:
MoonCode (MoonCode)
2024-08-16 20:33:00不用 pr 就怕人工合并的时候被加料 去跟谁解释 这资安扣分吧
作者: dog30111 (安) 2024-08-16 20:39:00
是我的话会站出来推动这件事，是个展现软实力的机会
作者:
DrTech (竹科管理处网军研发人员)
2024-08-16 20:50:00重点是程式码品质有在管。而不是各种花俏，形式化的流程。程式码品质，有在管PR可有可无。程式码品质没在管，再多review与流程，再多PR都没用。
作者:
luke72 (ccc)
2024-08-16 21:45:00留comment给开发者，嗯，很多公司开发者就是你自己啊就算是上市大公司，常常功能切很细，repo还是只有你在做跨部门合作的repo发PR，但一人两人的何必拘泥于这个
作者:
peter98 (新兵)
2024-08-16 21:50:00不会
作者:
luke72 (ccc)
2024-08-16 21:51:00我也见过一人repo走git flow，merge还要两人签核才能过然后某天半夜出bug要紧急修复，找不到人签核….只好动用admin权限先砍了他的policy再说
作者:
peter98 (新兵)
2024-08-16 22:13:00楼上luke说的就是标准的系统烂、没做好，Code review系统应该要有个override & merge
作者:
netburst (133 134 592)
2024-08-16 22:56:00没用ftp就万幸了
作者:
luke72 (ccc)
2024-08-17 00:01:00Code review & QA只是降低错误发生，不是免疫啦意外就是过去从未想过的状况，能看出的就不是意外了一个team两三个人，有几十个小repo很常见吧我想讲的就只是，大型repo的管理方法，并不是小型也适用
作者:
wulouise (在线上!=在电脑前)
2024-08-17 00:17:00github pr默认你一次全看，一条条看commit很麻烦..不过这就是设计理念不同的差异，至少还能多条看就很好了
脱裤子放屁而已 PR跟反对理由根本不冲突 单纯不会用会觉得卡通常就只是把git当备份机制 习惯想怎么改就怎么改 垃圾进main后又跟部属环境不一致 随时想魔改rollback
一条一条看不是就按next commit就好了吗=_=麻烦在哪
作者:
a731977 (卡哇邦卡)
2024-08-17 01:54:00不会
作者:
angusyu (〒△〒)
2024-08-17 02:30:00下篇文章：为什么不用Github
作者:
acgotaku (otaku)
2024-08-17 05:01:00就没 peer 可以 review 呀 我自己做自己的专案也懒得发
作者: poison5566 (已中毒) 2024-08-17 05:45:00
规模太小的团队就容易没有吧
作者: Firemaples (秋忆枫红) 2024-08-17 08:26:00
遇过不 review，开发不切 branch，全靠人力 QA 管品质的公司有 review 已经很不错了
作者: qazwsx12 (SexAnimal) 2024-08-17 10:24:00
我觉得质疑的也很怪..有这功能为啥不用，没有缺点都是优点啊！
作者:
wulouise (在线上!=在电脑前)
2024-08-17 13:11:00他一条render一次没办法快速切吧，有办法设定请告诉我..
作者:
Arbin (路人_Lv菜逼八)
2024-08-17 15:36:00还在用SVN的公司：
作者: yamagishi (山岸刑务官) 2024-08-17 15:49:00
原PO是在说优点那么多又没什么麻烦怎么不用PR
有 review 就赢了，多的是开 PR 直接 approve
你可以直接跟对方讨论优缺点 回来这里优越发一篇是要干嘛
作者:
pot1234 (锅子)
2024-08-17 21:46:00gerrit好像没用pr
作者:
LiebeLion (IchLiebeDich)
2024-08-17 21:56:00有commit就能review啊在branch code一样可以留comment
作者:
qrtt1 (有些事，有时候。。。)
2024-08-17 22:55:00有 PR 才好接自动测试或是相关的 workflow
作者:
iamshiao (CircleHsiao)
2024-08-17 23:55:00既然都要 review 了，用 PR 比较方便吧
作者: luappc (luappc) 2024-08-18 18:04:00
待过使用TFS+Git的公司，走Git flow，每个同事分支权限开到最大，通常都自己直接Merge develop给QA测试，根本没人用过TFS内建的PR功能，出问题再用git blame查是被谁改的
作者: smch (打哈哈) 2024-08-19 08:36:00
有review就不错了
前公司没在review 用SVN 没在开分支全部人往主线传QQ
作者: Hitmear (尸殌化液) 2024-08-19 13:21:00
听起来是svn workflow，这就习惯而已又没对错
小公司还在给你玩官僚那套那早倒了没事找事做是大公司赚钱后没事干的特权
作者: ashlikewing 2024-08-20 20:49:00
有了PR比较好review 是什么概念
作者:
NDark (溺于黑暗)
2024-08-20 21:00:00部分的工程师偏好用文字沟通 也许一来一往比较有生产力
作者: mm58307533 2024-08-24 19:17:00
一堆根本不review的公司也发PR
作者:
knives 2024-08-25 16:56:00重要的是把事情做好
作者: MonyemLi (life) 2024-08-28 18:46:00
各种公司都有，看你可否接受