今年年初我朋友面試進到一間港商，是一家電商小公司，最近跟他吃飯在聊公司的開發流
程
聊著聊著，竟然發現他們有使用 Github 但卻沒有發 PR
流程大概就是
切 branch -> 開發 -> 做完丟 branch name 給上頭 review
我一聽就覺得超怪，我朋友一開始進去也有問其他同事，但他們就是一臉很正常的樣子，
他之後也習以為常了
有用 Github 但不發 PR 的公司真的是第一次聽到...

有沒有一種可能是你見過的世面太少

不會

就是用不用這功能而已，做得也沒哪裡不一樣還是你覺得用什麼需求一定要用到PR才能做到

至少有review了

是覺得有發pr比較正式吧

Linus 也沒用PR 該怎麼辦

trunk based development:

方法(any)是靈活的 本質(review)才是重要的

肯定有段故事的

有review就不錯了吧…

至少有review 前公司不review還會在production branch開發

沒有特別說明為何這樣做的話 就是雷

PR只是一種merge的備忘錄，只要事情沒有多到記不住。merge也可以達到相同功能。當然搭配自動測試這是兩件事。

小公司有啥好意外 功能做出來賣錢才是重點

這就像是一人開發要不要用issue tracking

發pr有法律規定嗎？

如果事情沒有多到記不住自己不用裝模作樣開issue給自己對於更直接當面討論的團隊來說，說不定PR才是繞路。

只是流程不一樣而已 還是有review

沒有review就不用PR MR啦

但有發 PR 這流程會讓 review 變得輕鬆點 => 不一定

同樓上

有真review就屌打大部分公司了...

看起來只是你習慣用github的UI而已

大家有默契就好了

Real man test on production

團隊才幾個人發PR是能多賺錢嗎？repo搞不好是單人開發一堆新手看了廣告文，就想拿5000人團隊制度套到5人團隊

git的具體使用流程應該是配合公司吧有pr就有pr，沒有也不會怎樣吧

有可能剛學會怎麼用git，沒時間也沒心力測試這個流程

pr是github的功能吧？如果只是把github當git server沒pr也ok

我覺得上面部份人其實不懂 PR，所以看不懂你的納悶，哈哈

我看完留言想法也跟樓上一樣

pr都不懂別想說git flow自己管是多會管理拉..

小團隊還好吧 如果一個repo有上百個人在開發哪可能非用不行

內文加留言 滿滿的工程師相輕

有可能是在Review完由Reviewer Merge，那不一定要MR, PR

公司就是 有分不同分支開發最後由主開發人來merge 不懂為什麼不用 PR就好

總比要大家全部都直接上main好吧

看公司吧，我之前公司是小接案公司，功能在 dev branch上沒什麼問題就給客戶看了

一人開發 沒有大家

github pr不適合per commit review但是交流還是方便很多沒錯啦

就風格不同吧 我遇過不同team 有的會發 有的直上的公司也遇過流程上會先後經過design review、code review這我就覺得發不發都還好當然完全不管的 應該連討論都不用啦

不用 pr 就怕人工合併的時候被加料 去跟誰解釋 這資安扣分吧

是我的話會站出來推動這件事，是個展現軟實力的機會

是不是南京復興附近那間哈哈哈哈

重點是程式碼品質有在管。而不是各種花俏，形式化的流程。程式碼品質，有在管PR可有可無。程式碼品質沒在管，再多review與流程，再多PR都沒用。

留comment給開發者，嗯，很多公司開發者就是你自己啊就算是上市大公司，常常功能切很細，repo還是只有你在做跨部門合作的repo發PR，但一人兩人的何必拘泥於這個

不會

我也見過一人repo走git flow，merge還要兩人簽核才能過然後某天半夜出bug要緊急修復，找不到人簽核….只好動用admin權限先砍了他的policy再說

樓上luke說的就是標準的系統爛、沒做好，Code review系統應該要有個override & merge

沒用ftp就萬幸了

Code review & QA只是降低錯誤發生，不是免疫啦意外就是過去從未想過的狀況，能看出的就不是意外了一個team兩三個人，有幾十個小repo很常見吧我想講的就只是，大型repo的管理方法，並不是小型也適用

github pr預設你一次全看，一條條看commit很麻煩..不過這就是設計理念不同的差異，至少還能多條看就很好了

脫褲子放屁而已 PR跟反對理由根本不衝突 單純不會用會覺得卡通常就只是把git當備份機制 習慣想怎麼改就怎麼改 垃圾進main後又跟部屬環境不一致 隨時想魔改rollback

一條一條看不是就按next commit就好了嗎=_=麻煩在哪

不會

下篇文章：為什麼不用Github

就沒 peer 可以 review 呀 我自己做自己的專案也懶得發

規模太小的團隊就容易沒有吧

遇過不 review，開發不切 branch，全靠人力 QA 管品質的公司有 review 已經很不錯了

我覺得質疑的也很怪..有這功能為啥不用，沒有缺點都是優點啊！

他一條render一次沒辦法快速切吧，有辦法設定請告訴我..

ㄤㄧ

還在用SVN的公司：

原PO是在說優點那麼多又沒甚麼麻煩怎麼不用PR

有 review 就贏了，多的是開 PR 直接 approve

你可以直接跟對方討論優缺點 回來這裡優越發一篇是要幹嘛

我的感覺就是早期用SVN，後來轉移到git的公司

gerrit好像沒用pr

有commit就能review啊在branch code一樣可以留comment

有 PR 才好接自動測試或是相關的 workflow

既然都要 review 了，用 PR 比較方便吧

待過使用TFS+Git的公司，走Git flow，每個同事分支權限開到最大，通常都自己直接Merge develop給QA測試，根本沒人用過TFS內建的PR功能，出問題再用git blame查是被誰改的

你可以問主管啊問我們怎麼知道

有review就不錯了

前公司沒在review 用SVN 沒在開分支全部人往主線傳QQ

真的 有review就不錯了

你問一下主管就知道了阿...

聽起來是svn workflow，這就習慣而已又沒對錯

沒拿usb傳給你不錯了

小公司還在給你玩官僚那套那早倒了沒事找事做是大公司賺錢後沒事幹的特權

有了PR比較好review 是什麼概念

部分的工程師偏好用文字溝通 也許一來一往比較有生產力

又是看了幾本書開始檢討別人嗎？

一堆根本不review的公司也發PR

重要的是把事情做好

各種公司都有，看你可否接受