版本控管的重要概念

前言
版本控管系統（以下簡稱VCS）－稱的上是軟體品質相關的基礎建設裡面，最重要的一個。也是團隊開發、系統開發的基底，甚至只要是開發軟體系統，就應該採用版本控管。

但這篇文章要說的，不是介紹哪個工具怎麼使用，而是版本控管的概念。因為雖然有了工具，但還是太多太多的developer不知道該怎麼使用版本控管，導致版本控管僅有名無實，只是個同檔名多版本的檔案系統。

透過這一篇文章，希望可以給大家在開發工法上一點參考，或是當作導入版控的guidance。如果您已經有在用VCS(Version Control System)，也希望當作一個review的參考，看看您的團隊是否還有改進空間。

VCS必備三元素

1. 保留修訂記錄：開發人員要能輕易透過VCS取得先前的版本，復原與檢視歷史紀錄。
2. 連結性：所有開發人員都必須能夠存取VCS，且VCS必須是存取Source Code的唯一途徑。如果有人需要取得最新版本的程式碼，必定得透過VCS。
3. 不可分割的交易：倘若需一次修改多個檔案，則應將多個檔案視為不可分割的單元，也就是有交易的觀念。異動要嘛一次全都成功，要嘛全都失敗。否則可能導致版本錯亂。

循環與步驟

1. 從版本庫取得最新版本的程式，一定要可以建置成功。
2. 將要修改的程式簽出（檔案鎖定式的VCS）
3. 修改完程式。
4. 從版本庫更新最新版的程式， 若有conflict則merge。
5. 最新版的程式要能建置成功。
6. 整批簽入更新過的程式。

少了一步，則可能導致版本庫上的程式碼無法建置成功，或導致版本庫上非最新一個階段的程式碼。

另外，第二個鎖定步驟會跟著不同的VCS而有不同的處理。倘若為非檔案鎖定式的VCS，又有同時開發同一支程式的必要性，那只需應付後面的merge。但如果conflict的解決成本過高，建議還是要lock，迫使需要同時開發的成員進行溝通。

不可改變的基本原則

1. 版本庫上的所有程式一定要能建置成功。
2. 一旦建置失敗，應該將修復的任務提升為團隊第一優先的任務。
3. 簽入後，一定要保證自己的所有程式與版本庫一致。所以簽入前要再更新最新版，再建置通過，才能簽入。
4. 每次簽入的說明，務必要寫清楚修改的內容與範圍。說明內容絕對不要出現的情況：只有『新增』、『修改』等字眼，或是只有『日期』，『作者』等字眼。
5. 不必要的衍生性檔案，不要簽入。

日常作業實際範例

1. 每個人每天準備開始coding時，先檢查自己的程式與版本庫有哪些是不一致的。
2. 若不一致的檔案為『非自己簽出正在修改』的，則更新最新版。
3. 更新完開始coding前，檢查是否可以建置成功。
4. 若建置失敗，則請project leader或build owner，或是直接找到導致建置失敗的負責人，將問題修復。
5. 若修復可能得花比較多的時間，則將有問題的程式rollback回上一版，或回到沒有問題的版本，讓建置可以成功。
6. 著手開始coding。
7. 每天下班前，應至少要將手上的程式修改到可以建置成功，並更新最新的版本庫資料，再建置成功。
8. 將自己的程式簽入版本庫，就可以下班。

重要習慣

1. 持續簽入：
   持續簽入是一個重要的好習慣，個人建議一天至少要簽入一次，也就是下班前至少要簽入一版告一段落且可以與最新的版本庫建置成功的版本。既可以免去個人硬體 發生問題的風險，重要的是可以即時整合整個團隊的程式碼。確定大家的程式碼，都在規定與規劃的方向上協同運作。透過CI與品質檢測工具，更可以及早發掘出 程式的壞味道以及架構上需要重構的部分。
2. 有時衝突(conflict)不是壞事，不要害怕衝突：
   系統整合、程式整合，發現問題的時間點越晚，修復的成本越高。每一個簽入的循環，都可以及早發現團隊成員的程式碼，是否可以正常且品質良好的協同運作。每 一次正常的衝突，都是在省去後續龐大的整合成本。修復衝突，可以讓成員之間更瞭解彼此的程式碼如何運作，也可藉此發現更好的設計方式。
3. 簽入前一定要做的事：（若建置需要很久的時間，可省略第一步，只要確認目前本機程式是沒問題的）
   1. 建置
   2. 建置成功後，從VCS更新最新版的程式（包括單元測試）
   3. 再建置
   4. 再建置成功後，跑單元測試
   5. 單元測試都順利通過後，簽入。
4. 善用分支(Branch)：
   使用分支來隔離變動，讓團隊成員可以更有效的針對彼此要修正的點來修正系統。但分支得有比較好的制度與規劃，濫用分支可能導致合併回Truck時，天下大亂。至少，在做每個重要版本release時，要分出Branch來做baseline。
5. 善用標籤：
   好的標籤不只可以讓所有成員（甚至未來成員）容易理解，也可以透過Shell Script等工具來進行自動化建置、部署等動作。
6. 『簽入原則』、『封閉簽入』與『CI自動建置』
   1. 在TFS中，可以設定簽入原則，要簽入程式碼之前，會先檢查是否通過檢查，才能簽入。
   2. 有的VCS，可以設定簽入前檢查目前簽入的版本，是否能與版本庫上最新的程式建置成功，成功，才可以簽入版本庫。這是一個很棒的設計，如果您用的VCS有提供這個功能，千萬不要錯過。
   3. CI自動建置的部分，則會在後續的文章中提及較詳細的介紹，環環相扣，有了CI以及其他品質檢測工具，可以讓我們每次版本庫的異動，都馬上知道品質指標是否改變，是否簽入的程式碼發生了不符預期的執行結果。

結論

1. 每個人都要對團隊負責。
2. 每個人都要對版本庫負責。
3. 不要害怕conflict，不要害怕merge。持續簽入是一個好習慣。

原始文章出自於此