Source Control 碰到的難題 3

  • [Problem 3] Difficulty of Merge

前面說過,如果前後兩個修正有衝突(更改了同一個檔案),那加入後面這個修正的工程師必須負責解決其中的衝突,這個解決的過程我們稱之為 merge 。

通常 merge 有兩種方式,一種是人工,另一種是自動。人工的意思是說工程師必須把每一個有衝突的檔案都打開,用手動的方式把兩份檔案合併成一份。而自動則是把工作交給 source control system 來做,讓軟體自己去判斷檔案該如何合併。兩種方式都各有優缺點,人工的優點是準確性很高,只要工程師不是閉著眼睛在 merge ,通常不會有大問題。但是缺點就是費時,如果檔案有十幾個、甚至幾十個,那不知道要 merge 到哪一年去,而且負責 merge 的工程師必須要完全看懂前後兩個修正的內容,才有辦法做出正確的判斷。反過來說,auto merge 的最大優點就是省時,通常幾秒鐘內就可以解決問題。可是它有個致命的缺點,就是沒辦法保證百分之百的準確。嚴格來講,我之前用的 Vault 和現在用的 SVN 在 auto merge 上的準確度幾乎已經是100%了,在我用的這六年來,只發生過不到三次的錯誤(也許是我儘量避免用 auto merge 的關係)。但就是因為一朝被蛇咬,十年怕草繩,我到現在還不是完全相信 auto merge ,而且就算是用 auto merge ,我也會再用肉眼檢查一遍是不是正確,我認為這是比較實際的作法。

不管是人工或自動,讓 merge 不要出錯的方法就是讓需要 merge 的檔案與幅度儘量簡單。而讓 merge 儘量簡單的方法就是一次不要改太多的檔案,或是儘量在最短的時間內把檔案 commit 回去,這樣就能減少和別人衝突的機會,以致於減小 merge 的範圍。可是有時候同時在解決問題的工程師太多,或是問題牽涉的範圍太大,你不太可能有辦法完全避免檔案的衝突,換句話說 merge 絕對是難以避免的,也因此 merge 這件事必須要當成一項很慎重的事來進行,因為如果你花了幾個星期的時間解了一個 bug ,可是在最後 merge 的時候出了錯,導致前功盡棄,豈不是很可惜?

記得我之前曾經抱怨過程式的 style 不能修改?有很大的理由就是這會造成其他工程師在 merge 時的困擾。 merge 牽涉的範圍如果太大,無形中會要求負責 merge 的工程師對修改的內容有更深的了解,否則沒有辦法保證 merge 的結果是正確的。這一般來講不是受到歡迎的事,因為工程師通常都很忙,所以他們不想了解你是怎麼解決你的問題的,他們只在乎他們自己的bug能趕快解決就好,其他的事一概不重要。久而久之,程式碼的品質與可讀性自然就這在這種多一事不如少一事的文化被犧牲了。

廣告

About Weicheng Chu

創業中,微碧愛普科技 (www.weibyapp.com) 已婚, 有一對雙胞胎兒子, 現居住在美國加州、台灣台中
本篇發表於 軟體工程, Source Control 並標籤為 , 。將永久鏈結加入書籤。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s