如題，好奇想問一下
基本上在有正常版控的條件下
這種情況是不是根本不該發生？
尤其是開發周期尚未結束，沒有要交接
每個人負責的部分
最小單位應該直接用檔案切開
一個檔案只會有一個人在維護、push code
即使是超龐大Class
也應該儘量切成不同小Class
然後利用繼承、封裝、多型分工出去才對
因為我常遇到為了rebase
需要一定程度搬動到別人的code
可能就是往前往後個幾行
或是在相同段落內插入幾行自己的
這種情況是否就代表分工不明確、模組化沒做好?
是否有甚麼情況是讓這件事可以被接受的
還是這種情況本來就家常便飯
單純我太龜毛而已XD
這就跟隕石開發一樣阿，不應該，但大家都習慣了只要沒天兵直接蓋過去就好了
作者:
loadingN (sarsaparilla)
2023-03-20 13:25:00自己解conflict啊
作者:
brucetu (sec)
2023-03-20 13:48:00那些被你搬動的code就是比你早commit啊 那就是既有程式碼了 三分鐘前才commit進去的code 跟上個月寫好commit進去的code有什麼分別嗎
作者:
acgotaku (otaku)
2023-03-20 13:54:00就很常見吧 誰晚進去 誰就rebase 測試寫好不要影響對方
你說的就是svn的概念，就是因為不好用才慢慢改成 git你能想像為了改一個檔案等一個星期的痛苦嗎？
為何會很常遇到呀，分工通常是每個人會開發不一樣 component ，還是剛好都一直碰到共用的地方？
作者:
surimodo (好吃棉花糖)
2023-03-20 14:59:00猜拳決定誰處理衝突
作者:
touurtn (vv)
2023-03-20 15:08:00單元測試覆蓋到就會安心點
理論上然樓主說的算對,但現實上,跟你合作的人,程式碼品質就是無法預期.要是他又是你客戶公司的正職RD,那你能怎樣? 跟你的客戶PM抱怨說你們家誰誰誰寫code很髒??或是你自己開公司當最高的甲方
作者:
quickey (色肥宅)
2023-03-20 16:38:00丟給chatgpt請他優化就好
作者:
Petyr (小指頭)
2023-03-20 17:38:00這不是很正常的事情嗎 版控某方面也是預防被蓋過去啊
作者:
wulouise (在線上!=在電腦前)
2023-03-20 18:27:00就沒切好，檔案改了又沒查，你UT不給他過不給merge就好
作者:
jej (晃奶大馬桶)
2023-03-20 18:35:00看起來怪怪的 這是大家都維護同一個branch的意思嗎？如果不同branch 就是給衰小的人merge本文中提到的rebase是指你們上到master很頻繁嗎？
開發專案照檔案切負責範圍？？？第一次聽到，長見識了
作者:
gigayaya (gigayaya)
2023-03-20 19:29:00感覺你們該做的是切branch來最小化這個問題
作者:
siriusu (かがみは俺の嫁。)
2023-03-20 19:40:00衝突很常見啊，尤其團隊規模一大自然避不開
你要PR前本來就要rebase 跟是不是branch有啥關係
作者:
Lipraxde (Lipraxde)
2023-03-20 20:28:00版本控制讓多人對同一段 code 貢獻變得可能，衝突時解conflict 很正常，而往往問題不是在 conflict，而是在有人 code 寫太爛
會容易改到同一段code或同一個function是你們本身架構上就有問題 沒做好solid吧
作者: howardsun 2023-03-20 21:44:00
超正常啊，公司一個人只負責特定的程式碼，會滿危險的，沒辦法互相 cover
作者:
wwndbk (黑人問號)
2023-03-20 22:48:00vscode live share
作者:
umum29 (....)
2023-03-21 00:24:00正常 尤其有兩三個長期專案在跑時 常會影響其他人其實這也是CICD的精神 一但commit就要做integration test就算模組切的在細 都有可能遇到多人開發conflict的狀況
最小單位用檔案切開 除非你們真的湊巧 他加欄位你修功能不過這是理想的情境 專案頻頻發生衝突這並不正常確實做到單一職責 切開之後別人的code多髒都不關你事
作者: k798976869 (kk) 2023-03-21 07:54:00
你自己不就有答案了 你有空幫忙切開封裝啊
作者:
abcf (悠哉悠哉的魚)
2023-03-21 08:21:00怎麼切都還是會有可能衝突，尤其是不同bug卻改到相近的區塊上面說什麼模組切的好就不會的都是唬爛你的，講誰都會講。
作者:
yyc1217 (somo)
2023-03-21 11:07:00同時間不同人頻繁改同一個段落確實很奇怪 也許可以用unittest確保執行成果符合預期
作者: hidog (.....) 2023-03-21 11:34:00
conflict無法完全避免喔
作者: internetms52 (Oaide) 2023-03-21 12:38:00
你想一下開放封閉原則你就會發現他不符合，但礙於每個人現在都有新的功能要開發，我建議你們各自寫一個擴充版本跟測試，以後找另一個人重構，除非你們有一個大神直接重構成很好的樣子，不然一直改會很痛苦
作者:
jej (晃奶大馬桶)
2023-03-21 12:42:00樓上 理想很豐滿 現實和骨感是不想回家了的意思嗎？
作者: k798976869 (kk) 2023-03-21 12:55:00
慣老闆：浪費時間重構啥雞巴 能賺錢嗎
你動到別人可能在改的 code 時，就要有意識可能會 conflict。先跟對方確認沒有相依，有的話就約定好一個順序，看是誰要先誰要後
先寫測試 有測試保護再談重構 重構也不用特地請人寫重構是在有寫測試保護的情境下 自己找時間或順手重構
作者: s06yji3 (阿南) 2023-03-21 19:24:00
一般不太可能知道這個code同時有誰在改吧......
如果跑敏捷 也可以在daily standup講一下自己今天要處理的ticket做溝通啦…
作者:
jej (晃奶大馬桶)
2023-03-21 21:02:00樓上 多數的scrum master為了排除障礙短期見效 就是派衰小的人去merge阿XD他這個問題就有點像是工項拆解或是程式架構甚至到git branch的切割其中的某一項或是某幾項有問題乍看之下應該是無法在立會後短期奏效的issue
作者:
umum29 (....)
2023-03-22 00:47:00負責merge的人真的衰 所以我們是每週不同人輪流merge
作者: superpandal 2023-03-22 01:07:00
版控又不能控需求還有工作分派和時程組件分開再組裝稍微好點 不是一個一個serserver 強迫別人寫稍好的程式模組化
作者:
acgotaku (otaku)
2023-03-22 14:25:00這跟元件,solid 哪有什麼關係,任務分配下去 共用到哪些邏輯又不能控制你確保封裝邊界不要更改,如要大改 要通知大家有相依的先等你的發車在往下進行 如果有人比你急 你就晚點改
作者: superpandal 2023-03-22 19:55:00
功能本來就一環串一環 怎麼切看話事人功力力 我講的不是solid 是專案內kiss統整的人再把它串起來功能就完成了
相依於介面 改的人修內部邏輯 用的人DI介面 就不會衝突