[討論] 不發 PR 的公司會很怪嗎

看板 Soft_Job
作者 SuKamo (小書僮)
時間 2024-08-16 12:53:01
留言 115 ( 39推 4噓 72→ )
今年年初我朋友面試進到一間港商，是一家電商小公司，最近跟他吃飯在聊公司的開發流 程 聊著聊著，竟然發現他們有使用 Github 但卻沒有發 PR 流程大概就是 切 branch -> 開發 -> 做完丟 branch name 給上頭 review 我一聽就覺得超怪，我朋友一開始進去也有問其他同事，但他們就是一臉很正常的樣子， 他之後也習以為常了 有用 Github 但不發 PR 的公司真的是第一次聽到... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.64.184.20 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1723783983.A.146.html

留言

→ sisdad 有沒有一種可能是你見過的世面太少 08/16 13:06 1F
→ surfingbboy 不會 08/16 13:11 2F
推 t19960804 https://i.imgur.com/NwbP4T9.jpeg 08/16 13:15 3F
[討論] 不發 PR 的公司會很怪嗎
 3F
→ stepnight 就是用不用這功能而已，做得也沒哪裡不一樣 08/16 13:15 4F
→ stepnight 還是你覺得用什麼需求一定要用到PR才能做到 08/16 13:15 5F
比如說可以直接在你的 code 上去做評論 沒用的話就會變成是「在 xx function 內的某個 function...」，溝通起來就會沒那麼 直觀
→ Newtype 至少有review了 08/16 13:15 6F
推 t19960804 是覺得有發pr比較正式吧 08/16 13:18 7F
→ qoo1991 Linus 也沒用PR 該怎麼辦 08/16 13:20 8F
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:25:57
推 mercurycgt68 trunk based development: 08/16 13:26 9F
我們公司就是用 trunk based，每次 merge 回主線就是發 PR
→ bear1414 方法(any)是靈活的 本質(review)才是重要的 08/16 13:27 10F
推 abc0922001 肯定有段故事的 08/16 13:29 11F
推 Imin0905 有review就不錯了吧… 08/16 13:32 12F
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:34:12
推 feathergod 至少有review 前公司不review還會在production branc 08/16 13:35 13F
→ feathergod h開發 08/16 13:35 14F
噓 MoonCode 沒有特別說明為何這樣做的話 就是雷 08/16 13:37 15F
推 NDark PR只是一種merge的備忘錄，只要事情沒有多到記不住。merge 08/16 13:38 16F
→ NDark 也可以達到相同功能。當然搭配自動測試這是兩件事。 08/16 13:38 17F
推 lwecloud 小公司有啥好意外 功能做出來賣錢才是重點 08/16 13:40 18F
推 NDark 這就像是一人開發要不要用issue tracking 08/16 13:49 19F
→ Obama19 發pr有法律規定嗎？ 08/16 13:50 20F
→ NDark 如果事情沒有多到記不住自己不用裝模作樣開issue給自己 08/16 13:50 21F
我比較疑惑的點是明明有 PR 這個功能可以方便 code review，反而要用其他繞路的方式 來進行，覺得很奇怪
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:51:49
推 NDark 對於更直接當面討論的團隊來說，說不定PR才是繞路。 08/16 13:52 22F
→ answermangtr 只是流程不一樣而已 還是有review 08/16 13:54 23F
但有發 PR 這流程會讓 review 變得輕鬆點
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:57:05
→ shooter555 沒有review就不用PR MR啦 08/16 14:02 24F
→ nh60211as 但有發 PR 這流程會讓 review 變得輕鬆點 => 不一定 08/16 14:03 25F
推 NDark 同樓上 08/16 14:09 26F
推 abccbaandy 有真review就屌打大部分公司了... 08/16 14:36 27F
→ ssccg 看起來只是你習慣用github的UI而已 08/16 14:47 28F
→ bheegrl 大家有默契就好了 08/16 15:04 29F
推 chopinmozart Real man test on production 08/16 15:40 30F
→ luke72 團隊才幾個人發PR是能多賺錢嗎？repo搞不好是單人開發 08/16 15:48 31F
→ luke72 一堆新手看了廣告文，就想拿5000人團隊制度套到5人團隊 08/16 15:50 32F
→ zxc8787 git的具體使用流程應該是配合公司吧 08/16 15:56 33F
→ zxc8787 有pr就有pr，沒有也不會怎樣吧 08/16 15:56 34F
推 abc0922001 有可能剛學會怎麼用git，沒時間也沒心力測試這個流程 08/16 16:16 35F
推 wei115 pr是github的功能吧？如果只是把github當git server沒pr 08/16 16:25 36F
→ wei115 也ok 08/16 16:25 37F
推 jackflu 我覺得上面部份人其實不懂 PR，所以看不懂你的納悶，哈哈 08/16 16:36 38F
推 happy8649 我看完留言想法也跟樓上一樣 08/16 16:38 39F
→ alan3100 pr都不懂別想說git flow自己管是多會管理拉.. 08/16 17:43 40F
推 iamOsaka 小團隊還好吧 如果一個repo有上百個人在開發哪可能非 08/16 17:47 41F
→ iamOsaka 用不行 08/16 17:47 42F
→ moom50302 內文加留言 滿滿的工程師相輕 08/16 18:00 43F
→ henrylin8086 有可能是在Review完由Reviewer Merge，那不一定要M 08/16 18:44 44F
→ henrylin8086 R, PR 08/16 18:44 45F
推 crazwade 公司就是 有分不同分支開發最後由主開發人來merge 不懂 08/16 19:05 46F
→ crazwade 為什麼不用 PR就好 08/16 19:05 47F
噓 hegemon 總比要大家全部都直接上main好吧 08/16 19:05 48F
→ newbout 看公司吧，我之前公司是小接案公司，功能在 dev branch 08/16 19:30 49F
→ newbout 上沒什麼問題就給客戶看了 08/16 19:30 50F
推 TSMCfabXX 一人開發 沒有大家 08/16 19:38 51F
我認知中，發 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
推 wulouise github pr不適合per commit review 08/16 20:10 52F
→ wulouise 但是交流還是方便很多沒錯啦 08/16 20:10 53F
沒吧，你一個 PR 還是可以包很多 commit 進來一起 review 呀
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 20:14:12
→ Ekmund 就風格不同吧 我遇過不同team 有的會發 有的直上的公司 08/16 20:20 54F
→ Ekmund 也遇過流程上會先後經過design review、code review 08/16 20:20 55F
→ Ekmund 這我就覺得發不發都還好 08/16 20:20 56F
→ Ekmund 當然完全不管的 應該連討論都不用啦 08/16 20:21 57F
→ MoonCode 不用 pr 就怕人工合併的時候被加料 去跟誰解釋 這資安 08/16 20:33 58F
→ MoonCode 扣分吧 08/16 20:33 59F
→ dog30111 是我的話會站出來推動這件事，是個展現軟實力的機會 08/16 20:39 60F
推 wd122344556 是不是南京復興附近那間哈哈哈哈 08/16 20:46 61F
→ DrTech 重點是程式碼品質有在管。而不是各種花俏，形式化的流程。 08/16 20:50 62F
→ DrTech 程式碼品質，有在管PR可有可無。程式碼品質沒在管，再多re 08/16 20:50 63F
→ DrTech view與流程，再多PR都沒用。 08/16 20:50 64F
→ luke72 留comment給開發者，嗯，很多公司開發者就是你自己啊 08/16 21:45 65F
→ luke72 就算是上市大公司，常常功能切很細，repo還是只有你在做 08/16 21:46 66F
→ luke72 跨部門合作的repo發PR，但一人兩人的何必拘泥於這個 08/16 21:49 67F
→ peter98 不會 08/16 21:50 68F
→ luke72 我也見過一人repo走git flow，merge還要兩人簽核才能過 08/16 21:51 69F
→ luke72 然後某天半夜出bug要緊急修復，找不到人簽核…. 08/16 21:51 70F
→ luke72 只好動用admin權限先砍了他的policy再說 08/16 21:52 71F
→ peter98 樓上luke說的就是標準的系統爛、沒做好，Code review系統 08/16 22:13 72F
→ peter98 應該要有個override & merge 08/16 22:13 73F
→ netburst 沒用ftp就萬幸了 08/16 22:56 74F
→ luke72 Code review & QA只是降低錯誤發生，不是免疫啦 08/17 00:01 75F
→ luke72 意外就是過去從未想過的狀況，能看出的就不是意外了 08/17 00:04 76F
→ luke72 一個team兩三個人，有幾十個小repo很常見吧 08/17 00:06 77F
→ luke72 我想講的就只是，大型repo的管理方法，並不是小型也適用 08/17 00:07 78F
推 wulouise github pr預設你一次全看，一條條看commit很麻煩..不過 08/17 00:17 79F
→ wulouise 這就是設計理念不同的差異，至少還能多條看就很好了 08/17 00:17 80F
→ alan3100 脫褲子放屁而已 PR跟反對理由根本不衝突 單純不會用 08/17 00:58 81F
→ alan3100 會覺得卡通常就只是把git當備份機制 習慣想怎麼改就怎麼 08/17 01:03 82F
→ alan3100 改 垃圾進main後又跟部屬環境不一致 隨時想魔改rollback 08/17 01:05 83F
推 happy8649 一條一條看不是就按next commit就好了嗎=_=麻煩在哪 08/17 01:17 84F
噓 a731977 不會 08/17 01:54 85F
→ angusyu 下篇文章：為什麼不用Github 08/17 02:30 86F
→ acgotaku 就沒 peer 可以 review 呀 我自己做自己的專案也懶得發 08/17 05:01 87F
推 poison5566 規模太小的團隊就容易沒有吧 08/17 05:45 88F
推 Firemaples 遇過不 review，開發不切 branch，全靠人力 QA 管品 08/17 08:26 89F
→ Firemaples 質的公司 08/17 08:26 90F
→ Firemaples 有 review 已經很不錯了 08/17 08:26 91F
推 qazwsx12 我覺得質疑的也很怪..有這功能為啥不用，沒有缺點都是 08/17 10:24 92F
→ qazwsx12 優點啊！ 08/17 10:24 93F
推 wulouise 他一條render一次沒辦法快速切吧，有辦法設定請告訴我.. 08/17 13:11 94F
推 geoege022702 ㄤㄧ 08/17 14:32 95F
推 Arbin 還在用SVN的公司： 08/17 15:36 96F
推 yamagishi 原PO是在說優點那麼多又沒甚麼麻煩怎麼不用PR 08/17 15:49 97F
推 Phenomenon 有 review 就贏了，多的是開 PR 直接 approve 08/17 18:00 98F
噓 B0988698088 你可以直接跟對方討論優缺點 回來這裡優越發一篇是 08/17 18:36 99F
→ B0988698088 要幹嘛 08/17 18:36 100F
→ qpowjohn 我的感覺就是早期用SVN，後來轉移到git的公司 08/17 19:07 101F
推 pot1234 gerrit好像沒用pr 08/17 21:46 102F
→ LiebeLion 有commit就能review啊 08/17 21:56 103F
→ LiebeLion 在branch code一樣可以留comment 08/17 21:56 104F
推 qrtt1 有 PR 才好接自動測試或是相關的 workflow 08/17 22:55 105F
→ iamshiao 既然都要 review 了，用 PR 比較方便吧 08/17 23:55 106F
推 luappc 待過使用TFS+Git的公司，走Git flow，每個同事分支權限開 08/18 18:04 107F
→ luappc 到最大，通常都自己直接Merge develop給QA測試，根本沒人 08/18 18:04 108F
→ luappc 用過TFS內建的PR功能，出問題再用git blame查是被誰改的 08/18 18:04 109F
→ notimenofree 你可以問主管啊問我們怎麼知道 08/19 05:59 110F
推 smch 有review就不錯了 08/19 08:36 111F
→ bean90638 前公司沒在review 用SVN 沒在開分支全部人往主線傳QQ 08/19 09:06 112F
推 MonkeyCL 真的 有review就不錯了 08/19 11:01 113F
推 lin70208 你問一下主管就知道了阿... 08/19 12:47 114F
推 Hitmear 聽起來是svn workflow，這就習慣而已又沒對錯 08/19 13:21 115F