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