PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (小書僮)時間3月前 (2024/08/16 12:53), 3月前編輯推噓37(41推 4噓 79→)
留言124則, 72人參與, 2月前最新討論串1/1
今年年初我朋友面試進到一間港商，是一家電商小公司，最近跟他吃飯在聊公司的開發流 程 聊著聊著，竟然發現他們有使用 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
→
08/16 13:06, 3月前 , 1F
有沒有一種可能是你見過的世面太少
08/16 13:06, 1F
→
08/16 13:11, 3月前 , 2F
不會
08/16 13:11, 2F
推
08/16 13:15, 3月前 , 3F
08/16 13:15, 3F
→
08/16 13:15, 3月前 , 4F
就是用不用這功能而已，做得也沒哪裡不一樣
08/16 13:15, 4F
→
08/16 13:15, 3月前 , 5F
還是你覺得用什麼需求一定要用到PR才能做到
08/16 13:15, 5F
比如說可以直接在你的 code 上去做評論 沒用的話就會變成是「在 xx function 內的某個 function...」，溝通起來就會沒那麼 直觀
→
08/16 13:15, 3月前 , 6F
至少有review了
08/16 13:15, 6F
推
08/16 13:18, 3月前 , 7F
是覺得有發pr比較正式吧
08/16 13:18, 7F
→
08/16 13:20, 3月前 , 8F
Linus 也沒用PR 該怎麼辦
08/16 13:20, 8F
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:25:57
推
08/16 13:26, 3月前 , 9F
trunk based development:
08/16 13:26, 9F
我們公司就是用 trunk based，每次 merge 回主線就是發 PR
→
08/16 13:27, 3月前 , 10F
方法(any)是靈活的 本質(review)才是重要的
08/16 13:27, 10F
推
08/16 13:29, 3月前 , 11F
肯定有段故事的
08/16 13:29, 11F
推
08/16 13:32, 3月前 , 12F
有review就不錯了吧…
08/16 13:32, 12F
※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:34:12
推
08/16 13:35, 3月前 , 13F
至少有review 前公司不review還會在production branc
08/16 13:35, 13F
→
08/16 13:35, 3月前 , 14F
h開發
08/16 13:35, 14F
噓
08/16 13:37, 3月前 , 15F
沒有特別說明為何這樣做的話 就是雷
08/16 13:37, 15F
推
08/16 13:38, 3月前 , 16F
PR只是一種merge的備忘錄，只要事情沒有多到記不住。merge
08/16 13:38, 16F
→
08/16 13:38, 3月前 , 17F
也可以達到相同功能。當然搭配自動測試這是兩件事。
08/16 13:38, 17F
推
08/16 13:40, 3月前 , 18F
小公司有啥好意外 功能做出來賣錢才是重點
08/16 13:40, 18F
推
08/16 13:49, 3月前 , 19F
這就像是一人開發要不要用issue tracking
08/16 13:49, 19F
→
08/16 13:50, 3月前 , 20F
發pr有法律規定嗎？
08/16 13:50, 20F
→
08/16 13:50, 3月前 , 21F
如果事情沒有多到記不住自己不用裝模作樣開issue給自己
08/16 13:50, 21F
我比較疑惑的點是明明有 PR 這個功能可以方便 code review，反而要用其他繞路的方式 來進行，覺得很奇怪 ※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:51:49
推
08/16 13:52, 3月前 , 22F
對於更直接當面討論的團隊來說，說不定PR才是繞路。
08/16 13:52, 22F
→
08/16 13:54, 3月前 , 23F
只是流程不一樣而已 還是有review
08/16 13:54, 23F
但有發 PR 這流程會讓 review 變得輕鬆點 ※ 編輯: SuKamo (114.27.35.104 臺灣), 08/16/2024 13:57:05
→
08/16 14:02, 3月前 , 24F
沒有review就不用PR MR啦
08/16 14:02, 24F
→
08/16 14:03, 3月前 , 25F
但有發 PR 這流程會讓 review 變得輕鬆點 => 不一定
08/16 14:03, 25F
推
08/16 14:09, 3月前 , 26F
同樓上
08/16 14:09, 26F
推
08/16 14:36, 3月前 , 27F
有真review就屌打大部分公司了...
08/16 14:36, 27F
→
08/16 14:47, 3月前 , 28F
看起來只是你習慣用github的UI而已
08/16 14:47, 28F
→
08/16 15:04, 3月前 , 29F
大家有默契就好了
08/16 15:04, 29F
推
08/16 15:40, 3月前 , 30F
Real man test on production
08/16 15:40, 30F
→
08/16 15:48, 3月前 , 31F
團隊才幾個人發PR是能多賺錢嗎？repo搞不好是單人開發
08/16 15:48, 31F
→
08/16 15:50, 3月前 , 32F
一堆新手看了廣告文，就想拿5000人團隊制度套到5人團隊
08/16 15:50, 32F
→
08/16 15:56, 3月前 , 33F
git的具體使用流程應該是配合公司吧
08/16 15:56, 33F
還有 51 則推文
還有 2 段內文
噓
08/17 01:54, 3月前 , 85F
不會
08/17 01:54, 85F
→
08/17 02:30, 3月前 , 86F
下篇文章：為什麼不用Github
08/17 02:30, 86F
→
08/17 05:01, 3月前 , 87F
就沒 peer 可以 review 呀 我自己做自己的專案也懶得發
08/17 05:01, 87F
推
08/17 05:45, 3月前 , 88F
規模太小的團隊就容易沒有吧
08/17 05:45, 88F
推
08/17 08:26, 3月前 , 89F
遇過不 review，開發不切 branch，全靠人力 QA 管品
08/17 08:26, 89F
→
08/17 08:26, 3月前 , 90F
質的公司
08/17 08:26, 90F
→
08/17 08:26, 3月前 , 91F
有 review 已經很不錯了
08/17 08:26, 91F
推
08/17 10:24, 3月前 , 92F
我覺得質疑的也很怪..有這功能為啥不用，沒有缺點都是
08/17 10:24, 92F
→
08/17 10:24, 3月前 , 93F
優點啊！
08/17 10:24, 93F
推
08/17 13:11, 3月前 , 94F
他一條render一次沒辦法快速切吧，有辦法設定請告訴我..
08/17 13:11, 94F
推
08/17 14:32, 3月前 , 95F
ㄤㄧ
08/17 14:32, 95F
推
08/17 15:36, 3月前 , 96F
還在用SVN的公司：
08/17 15:36, 96F
推
08/17 15:49, 3月前 , 97F
原PO是在說優點那麼多又沒甚麼麻煩怎麼不用PR
08/17 15:49, 97F
推
08/17 18:00, 3月前 , 98F
有 review 就贏了，多的是開 PR 直接 approve
08/17 18:00, 98F
噓
08/17 18:36, 3月前 , 99F
你可以直接跟對方討論優缺點 回來這裡優越發一篇是
08/17 18:36, 99F
→
08/17 18:36, 3月前 , 100F
要幹嘛
08/17 18:36, 100F
→
08/17 19:07, 3月前 , 101F
我的感覺就是早期用SVN，後來轉移到git的公司
08/17 19:07, 101F
推
08/17 21:46, 3月前 , 102F
gerrit好像沒用pr
08/17 21:46, 102F
→
08/17 21:56, 3月前 , 103F
有commit就能review啊
08/17 21:56, 103F
→
08/17 21:56, 3月前 , 104F
在branch code一樣可以留comment
08/17 21:56, 104F
推
08/17 22:55, 3月前 , 105F
有 PR 才好接自動測試或是相關的 workflow
08/17 22:55, 105F
→
08/17 23:55, 3月前 , 106F
既然都要 review 了，用 PR 比較方便吧
08/17 23:55, 106F
推
08/18 18:04, 3月前 , 107F
待過使用TFS+Git的公司，走Git flow，每個同事分支權限開
08/18 18:04, 107F
→
08/18 18:04, 3月前 , 108F
到最大，通常都自己直接Merge develop給QA測試，根本沒人
08/18 18:04, 108F
→
08/18 18:04, 3月前 , 109F
用過TFS內建的PR功能，出問題再用git blame查是被誰改的
08/18 18:04, 109F
→
08/19 05:59, 3月前 , 110F
你可以問主管啊問我們怎麼知道
08/19 05:59, 110F
推
08/19 08:36, 3月前 , 111F
有review就不錯了
08/19 08:36, 111F
→
08/19 09:06, 3月前 , 112F
前公司沒在review 用SVN 沒在開分支全部人往主線傳QQ
08/19 09:06, 112F
推
08/19 11:01, 3月前 , 113F
真的 有review就不錯了
08/19 11:01, 113F
推
08/19 12:47, 3月前 , 114F
你問一下主管就知道了阿...
08/19 12:47, 114F
推
08/19 13:21, 3月前 , 115F
聽起來是svn workflow，這就習慣而已又沒對錯
08/19 13:21, 115F
→
08/19 21:24, 3月前 , 116F
沒拿usb傳給你不錯了
08/19 21:24, 116F
→
08/19 22:37, 3月前 , 117F
小公司還在給你玩官僚那套那早倒了
08/19 22:37, 117F
→
08/19 22:37, 3月前 , 118F
沒事找事做是大公司賺錢後沒事幹的特權
08/19 22:37, 118F
→
08/20 20:49, 3月前 , 119F
有了PR比較好review 是什麼概念
08/20 20:49, 119F
推
08/20 21:00, 3月前 , 120F
部分的工程師偏好用文字溝通 也許一來一往比較有生產力
08/20 21:00, 120F
推
08/23 19:59, 3月前 , 121F
又是看了幾本書開始檢討別人嗎？
08/23 19:59, 121F
→
08/24 19:17, 3月前 , 122F
一堆根本不review的公司也發PR
08/24 19:17, 122F
→
08/25 16:56, 3月前 , 123F
重要的是把事情做好
08/25 16:56, 123F
→
08/28 18:46, 2月前 , 124F
各種公司都有，看你可否接受
08/28 18:46, 124F
‣ 更多 SuKamo 的文章
文章代碼(AID): #1cljil56 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 SuKamo 的文章
文章代碼(AID): #1cljil56 (Soft_Job)