※ 引述《leolarrel (真.粽子无双)》之铭言： : A先commit , 然後B也要commit 时就冒出了"过时(out of date)",这很合理.接下来B就必 : 须合并A的更改,才能commit. 当B执行合并时,并不会产生冲突警告,接着B的档案就会变成 : L11 : L22 : L33 : L4 : 结果同事就说 "假如L3 是对B的工作上是很重要的一行,A不应该修改.结果A去改到了,B没 : 有收到警告" 我们的作法是, 每个 commit 的人有责任要确保 commit 进去的程式没有太 基本的问题, 譬如不能 compile 之类的. 当 B commit 的时候发现有更新, B 应该在 merge 後做最基本的测试, 试试自己负责的部分有没有被影响到, 确定没有大问题 B 才做 commit 的动作. 平常的 commit 这样大概就够了, 完整的测试就等 integration build 时交给 testing team 做了. 我们实际的经验, 这种多人同时改一个程式档, 互相影响的状况其实不多, 如果常常有这种情形发生, 很可能是你们程式架构不好, 或是 team 里面 每个 programmer 的权责没有很清楚. Merge conflict 只是凸显了这些问题而已. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 60.251.144.115