※ 引述《macbuntu (邀怪)》之銘言： : ※ 引述《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 只是凸顯了這些問題而已. 我們公司也在跑類似的模式. 下面是我們訂的規則 1) 準備 commit 前要做一次 svn update 把 working copy update 到最新 2) 在 svn update 時發現有 conflict, 他有責任搞清楚並 resolve 之 3) 然後要做一次 clean compile 並 full unit test 4) 要能夠 compile, 而 unit test 也要全通過, 才能 commit 5) commit 要在 project 頂端 commit, 不該選擇性地選 file commit, 修改也要一次過 commit, 不能一個一個地做 這樣的話, 絕大部份同時修改出的問題都能避免, 而 developer 有責任寫好自己的 unit test. 要是某功能對你很重要而你 又沒有 test, 而令人家改動後影響了你的功能但 unit test 不能detect 的話, 那就是你自己不對, 沒有做好 unit test. 當然, 總是會有很小很小的機會是兩人同時 commit 而把 repo 的壯 態搞亂, 但經驗告訴我, 只要謹守上面的規則, 一個 20 人的 team, 一年也不會出現一次這種問題. 同時我們也有一部 Continuous Integration (CI) server, 每十五分鐘取最新的 source code compile & unit test. 有任 何人 break build 的話很快就能 detect 得到, 當然, break build 的犯人要盡快 fix 好. 同時修改的工作模式要能跑得順利, 很大程度是要建基於 1) 遵守上面的規則 2) 乖乖做 Unit test 3) CI. 三點缺一不可 一點經驗的分享, 希望有用 :) alien --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 202.155.236.82