如题，好奇想问一下
基本上在有正常版控的条件下
这种情况是不是根本不该发生？
尤其是开发周期尚未结束，没有要交接
每个人负责的部分
最小单位应该直接用档案切开
一个档案只会有一个人在维护、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接口 就不会冲突