請在「持續整合」的原則下利用版本控制工具的合併功能
前一陣子在工作場所碰到一件事，我的同事抱怨 SVN 不能幫他合併他修改過的分支內容。我覺得很奇怪，因為我並沒有碰過這種情形。一開始我以為他是不熟悉 TortoiseSVN 工具，後來我實際看了他操作後，看到他竟然一次要合併近百份源碼檔，當場無言以對。
我記得我曾說過 SVN 可以幫我們程序員自動合併分支的源碼內容，並在衝突時提示我們。然而，在碰到同事這件例子後，我發覺我忘了加一個但書: 「請在持續整合(Continuous Integration)的原則下利用合併功能」。否則再好的版本控制工具也無法幫你合併。
程式員每天簽入他們的程式碼，而且整合好幾次。
當程式員完成修改後將它簽入時，心裡必須有所準備得要合併別人在之前先行簽入所作的改變。為了避免合併花費太長的時間，團隊的成員會頻繁地把模組簽入。
Robert Martin, 《敏捷軟體開發原則、樣式與實務》, 章節2.1.8: 持續整合
先說說我個人的使用習慣。首先，當我寫了一份源碼及測試案例後，即便只寫好類別的外觀宣告，我仍會提交(commit)。接著，我會按照類程內容的實作進度與重整範圍有規律地 提交源碼。而在上午午餐與下午下班前30分鐘左右，就會進行一次整合，並執行整合性測試案例組合 (test case suite)。當我需要利用 SVN 的「合併(merge)」功能時，基本上就是在整合之時。以我這種提交頻率，一次合併的源碼文件屈指可數(也就是小於10份源碼文件)，而且一天至少兩次。
在這種頻率下，SVN 的合併功能確實有效地幫我完成了幾乎全部的源碼合併動作。即使有衝突，一般也就兩、三處，按按滑鼠選擇要採用的段落就解決了。
我那同事的情形則相反。就我所知，他甚至隔了三、四天才做合併，而且已經修改了近百份源碼檔。於是，當他執行合併功能時，光跳出來的衝突提示就令人眼花繚亂了。還有一點，人是善忘的，經過兩、三天的時間後，他已經想不出來改過哪些地方以及為何而改。他必須逐一地反覆查看衝突段落的前後文，拿起電話聯絡其他修改者，才能決定那些段落要採用，而哪些段落要重寫。沒錯，就是重寫，這意味著有些地方的修改工作前功盡棄。
啊，差點忘了最重要的一件事。那就是他沒有寫測試案例的習慣(事實上，公司除我以外，大概都沒有這習慣，他們認為那是測試部門的工作)。而在這麼大規模的異動後，不難想像合併後的源碼是錯誤重重。於是重新測試與除錯，又是一件巨大的苦差事。
我記得那位同事後來大概又花了兩天的時間才把他那些源碼內容合併起來。現在，他每天下班前都一定會合併一次 (不過他還是沒有寫測試案例)。他抱怨 SVN 不能合併的次數終於變少了。
樂多舊回應