專案程式碼不得不兩線並進時， Mercurial 的簡單因應策略為何?

最近，我們的系統要作二周的使用者教育訓練，且接受他們的回饋意見，而系統功能離真正的完工還有一段小距離，因為他們可能會提出一些新的想法，若可行性高的話，我們也會把功能實作上去。

而這種「兩線並進」的程式碼維護該如何處理? 因為我們使用的是分散式版本控制器，所以這策略可分簡單及進階方法兩種，當然啦，進階方法必定有優點比簡單方法多一點，要不然，大家都用簡單方法不就得了。

首先，我們要先了解為什麼會有「兩線並進」的現象發生。

在作系統展示及教育訓練的時候，有可能會面臨到第一次出現的 bug ，因為這時候所輸入的資料、操作流程會因使用者的真實需求而與我們開發者在測試階段有所不同，造成我們會有 debug 的需求。但在這二周之間，除了去作教育訓練的人外，其他沒去的開發者會繼續作其他功能的設計，那系統程式碼也會有因新增功能而產生的修改。

那如果兩者所新增、修改的程式碼都在同一個儲存庫中，那是不是一定會發生開發者寫的新功能變成教育訓練時的新 bug 呢! 我相信會的。

所以這時候，一定要用兩線各自獨立運作的方式，才會避免雙方互挖牆腳。

首先介紹簡單方法：

在展示主機上，先作 hg clone ，得到一個 xxx 專案資料夾，然後再作一次 hg clone xxx xxx-bugfix 。這時候，我們使用 xxx-bugfix 來作系統展示之用，如果有 bug 的話，也直接修改在這個 xxx-bugfix 專案中，並把這些修改 push 回到 xxx 之中，而在 xxx 之中，我們則是作新功能(從伺服器 pull -u 來的)及 fixed bug 的合併。合併後再整個 push 回程式碼伺服器上。這樣一來，訓練者所作的 bug fix 也可以讓開發者獲得，而開發者寫的新功能不會影響訓練者使用的展示系統。

以上方法的確可以滿足「兩線並進」的需求，然而它有一些麻煩的事要處理，當訓練者在作 bug fix 時，他要不是在展示主機上直接修改，要不然就是把展示主機的 xxx-bugfix 抓回自己的電腦來處理，改回後，再放回展示主機，這造成了另一個問題，如果訓練者有兩個以上，而他們同時要作 bug fix 呢! 又回到 copy 的時光了，要不然就是在展示主機上再搞一個程式碼伺服器讓 xxx-bugfix 可以變成多人合作的 debug 專案。

Mercurial 的分散式架構讓「兩線並進策略」變得非常簡單，但如果只用了這一招，這有點小看了 Mercurial 的強大。

下節我將介紹使用 branch, merge 指令實現「兩線並進策略」。