PTT推薦

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

看板Soft_Job標題[討論] 不發 PR 的公司會很怪嗎作者
SuKamo
(小書僮)
時間推噓35 推:39 噓:4 →:75

今年年初我朋友面試進到一間港商,是一家電商小公司,最近跟他吃飯在聊公司的開發流程

聊著聊著,竟然發現他們有使用 Github 但卻沒有發 PR

流程大概就是
切 branch -> 開發 -> 做完丟 branch name 給上頭 review

我一聽就覺得超怪,我朋友一開始進去也有問其他同事,但他們就是一臉很正常的樣子,他之後也習以為常了

有用 Github 但不發 PR 的公司真的是第一次聽到...

--

※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.64.184.20 (臺灣)
PTT 網址

sisdad08/16 13:06有沒有一種可能是你見過的世面太少

surfingbboy08/16 13:11不會

t1996080408/16 13:15https://i.imgur.com/NwbP4T9.jpeg

圖 不發 PR 的公司會很怪嗎

stepnight08/16 13:15就是用不用這功能而已,做得也沒哪裡不一樣

stepnight08/16 13:15還是你覺得用什麼需求一定要用到PR才能做到

比如說可以直接在你的 code 上去做評論 沒用的話就會變成是「在 xx function 內的某個 function...」,溝通起來就會沒那麼 直觀

Newtype08/16 13:15至少有review了

t1996080408/16 13:18是覺得有發pr比較正式吧

qoo199108/16 13:20Linus 也沒用PR 該怎麼辦

※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:25:57

mercurycgt6808/16 13:26trunk based development:

我們公司就是用 trunk based,每次 merge 回主線就是發 PR

bear141408/16 13:27方法(any)是靈活的 本質(review)才是重要的

abc092200108/16 13:29肯定有段故事的

Imin090508/16 13:32有review就不錯了吧…

※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:34:12

feathergod08/16 13:35至少有review 前公司不review還會在production branc

feathergod08/16 13:35h開發

MoonCode08/16 13:37沒有特別說明為何這樣做的話 就是雷

NDark08/16 13:38PR只是一種merge的備忘錄,只要事情沒有多到記不住。merge

NDark08/16 13:38也可以達到相同功能。當然搭配自動測試這是兩件事。

lwecloud08/16 13:40小公司有啥好意外 功能做出來賣錢才是重點

NDark08/16 13:49這就像是一人開發要不要用issue tracking

Obama1908/16 13:50發pr有法律規定嗎?

NDark08/16 13:50如果事情沒有多到記不住自己不用裝模作樣開issue給自己

我比較疑惑的點是明明有 PR 這個功能可以方便 code review,反而要用其他繞路的方式 來進行,覺得很奇怪

※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:51:49

NDark08/16 13:52對於更直接當面討論的團隊來說,說不定PR才是繞路。

answermangtr08/16 13:54只是流程不一樣而已 還是有review

但有發 PR 這流程會讓 review 變得輕鬆點

※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:57:05

shooter55508/16 14:02沒有review就不用PR MR啦

nh60211as08/16 14:03但有發 PR 這流程會讓 review 變得輕鬆點 => 不一定

NDark08/16 14:09同樓上

abccbaandy08/16 14:36有真review就屌打大部分公司了...

ssccg08/16 14:47看起來只是你習慣用github的UI而已

bheegrl08/16 15:04大家有默契就好了

chopinmozart08/16 15:40Real man test on production

luke7208/16 15:48團隊才幾個人發PR是能多賺錢嗎?repo搞不好是單人開發

luke7208/16 15:50一堆新手看了廣告文,就想拿5000人團隊制度套到5人團隊

zxc878708/16 15:56git的具體使用流程應該是配合公司吧

zxc878708/16 15:56有pr就有pr,沒有也不會怎樣吧

abc092200108/16 16:16有可能剛學會怎麼用git,沒時間也沒心力測試這個流程

wei11508/16 16:25pr是github的功能吧?如果只是把github當git server沒pr

wei11508/16 16:25也ok

jackflu08/16 16:36我覺得上面部份人其實不懂 PR,所以看不懂你的納悶,哈哈

happy864908/16 16:38我看完留言想法也跟樓上一樣

alan310008/16 17:43pr都不懂別想說git flow自己管是多會管理拉..

iamOsaka08/16 17:47小團隊還好吧 如果一個repo有上百個人在開發哪可能非

iamOsaka08/16 17:47用不行

moom5030208/16 18:00內文加留言 滿滿的工程師相輕

henrylin808608/16 18:44有可能是在Review完由Reviewer Merge,那不一定要M

henrylin808608/16 18:44R, PR

crazwade08/16 19:05公司就是 有分不同分支開發最後由主開發人來merge 不懂

crazwade08/16 19:05為什麼不用 PR就好

hegemon08/16 19:05總比要大家全部都直接上main好吧

newbout08/16 19:30看公司吧,我之前公司是小接案公司,功能在 dev branch

newbout08/16 19:30上沒什麼問題就給客戶看了

TSMCfabXX08/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

wulouise08/16 20:10github pr不適合per commit review

wulouise08/16 20:10但是交流還是方便很多沒錯啦

沒吧,你一個 PR 還是可以包很多 commit 進來一起 review 呀

※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 20:14:12

Ekmund08/16 20:20就風格不同吧 我遇過不同team 有的會發 有的直上的公司

Ekmund08/16 20:20也遇過流程上會先後經過design review、code review

Ekmund08/16 20:20這我就覺得發不發都還好

Ekmund08/16 20:21當然完全不管的 應該連討論都不用啦

MoonCode08/16 20:33不用 pr 就怕人工合併的時候被加料 去跟誰解釋 這資安

MoonCode08/16 20:33扣分吧

dog3011108/16 20:39是我的話會站出來推動這件事,是個展現軟實力的機會

wd12234455608/16 20:46是不是南京復興附近那間哈哈哈哈

DrTech08/16 20:50重點是程式碼品質有在管。而不是各種花俏,形式化的流程。

DrTech08/16 20:50程式碼品質,有在管PR可有可無。程式碼品質沒在管,再多re

DrTech08/16 20:50view與流程,再多PR都沒用。

luke7208/16 21:45留comment給開發者,嗯,很多公司開發者就是你自己啊

luke7208/16 21:46就算是上市大公司,常常功能切很細,repo還是只有你在做

luke7208/16 21:49跨部門合作的repo發PR,但一人兩人的何必拘泥於這個

peter9808/16 21:50不會

luke7208/16 21:51我也見過一人repo走git flow,merge還要兩人簽核才能過

luke7208/16 21:51然後某天半夜出bug要緊急修復,找不到人簽核….

luke7208/16 21:52只好動用admin權限先砍了他的policy再說

peter9808/16 22:13樓上luke說的就是標準的系統爛、沒做好,Code review系統

peter9808/16 22:13應該要有個override & merge

netburst08/16 22:56沒用ftp就萬幸了

luke7208/17 00:01Code review & QA只是降低錯誤發生,不是免疫啦

luke7208/17 00:04意外就是過去從未想過的狀況,能看出的就不是意外了

luke7208/17 00:06一個team兩三個人,有幾十個小repo很常見吧

luke7208/17 00:07我想講的就只是,大型repo的管理方法,並不是小型也適用

wulouise08/17 00:17github pr預設你一次全看,一條條看commit很麻煩..不過

wulouise08/17 00:17這就是設計理念不同的差異,至少還能多條看就很好了

alan310008/17 00:58脫褲子放屁而已 PR跟反對理由根本不衝突 單純不會用

alan310008/17 01:03會覺得卡通常就只是把git當備份機制 習慣想怎麼改就怎麼

alan310008/17 01:05改 垃圾進main後又跟部屬環境不一致 隨時想魔改rollback

happy864908/17 01:17一條一條看不是就按next commit就好了嗎=_=麻煩在哪

a73197708/17 01:54不會

angusyu08/17 02:30下篇文章:為什麼不用Github

acgotaku08/17 05:01就沒 peer 可以 review 呀 我自己做自己的專案也懶得發

poison556608/17 05:45規模太小的團隊就容易沒有吧

Firemaples08/17 08:26遇過不 review,開發不切 branch,全靠人力 QA 管品

Firemaples08/17 08:26質的公司

Firemaples08/17 08:26有 review 已經很不錯了

qazwsx1208/17 10:24我覺得質疑的也很怪..有這功能為啥不用,沒有缺點都是

qazwsx1208/17 10:24優點啊!

wulouise08/17 13:11他一條render一次沒辦法快速切吧,有辦法設定請告訴我..

geoege02270208/17 14:32ㄤㄧ

Arbin08/17 15:36還在用SVN的公司:

yamagishi08/17 15:49原PO是在說優點那麼多又沒甚麼麻煩怎麼不用PR

Phenomenon08/17 18:00有 review 就贏了,多的是開 PR 直接 approve

B098869808808/17 18:36你可以直接跟對方討論優缺點 回來這裡優越發一篇是

B098869808808/17 18:36要幹嘛

qpowjohn08/17 19:07我的感覺就是早期用SVN,後來轉移到git的公司

pot123408/17 21:46gerrit好像沒用pr

LiebeLion08/17 21:56有commit就能review啊

LiebeLion08/17 21:56在branch code一樣可以留comment

qrtt108/17 22:55有 PR 才好接自動測試或是相關的 workflow

iamshiao08/17 23:55既然都要 review 了,用 PR 比較方便吧

luappc08/18 18:04待過使用TFS+Git的公司,走Git flow,每個同事分支權限開

luappc08/18 18:04到最大,通常都自己直接Merge develop給QA測試,根本沒人

luappc08/18 18:04用過TFS內建的PR功能,出問題再用git blame查是被誰改的

notimenofree08/19 05:59你可以問主管啊問我們怎麼知道

smch08/19 08:36有review就不錯了

bean9063808/19 09:06前公司沒在review 用SVN 沒在開分支全部人往主線傳QQ

MonkeyCL08/19 11:01真的 有review就不錯了

lin7020808/19 12:47你問一下主管就知道了阿...

Hitmear08/19 13:21聽起來是svn workflow,這就習慣而已又沒對錯

becca94508/19 21:24沒拿usb傳給你不錯了

lovebridget08/19 22:37小公司還在給你玩官僚那套那早倒了

lovebridget08/19 22:37沒事找事做是大公司賺錢後沒事幹的特權