如果沒有并行開發，基線也許就是版本機上的一個簡單文件夾。
如果進行并行開發，那么基線就是具有了指定標簽的版本的集合。
在進行并行開發的時候，我們希望基線是流動的，會隨著我們的期望變化。比如說我們在1.1版本捉蟲的時候開始了2.0版本的開發，我們希望2.0的起始版本保持與1.1的最終版本一致。這里基于一點假設，假設2.0版本不回全面改寫1.1版本的代碼，而是小部分的改動。這種假設依賴于良好的設計。在擴展功能的時候，對原有代碼的改動盡量少。假設我們有A1 - A10 10個文件，在2.0版本中，為了增加新的功能，我們改動了A9，A10兩個文件，在1.1版Preview以后，1.1版本中因為修改BUG，又改動了A8，A9兩個文件。我們要使2.0版本的初始代碼包含1.1版本的最總代碼，我們需要做的事情就是將A8按照上篇所介紹的第一種合并場景進行合并，即合并到基線中（簡單的移動基線標簽），而A9文件，則除了要合并到基線中意外，還要進行上篇所介紹的的第三種場景的合并，即將基線的變化合并到已經發生改變的2.0版本中（移動基線標簽并進行合并）。通常，基線變更涉及的文件數應該盡量少。
這就是流動的基線。因基線的變更需要許多人工判斷的介入，所以基線應該是穩定經受考驗的版本。我們要保證基線的穩定性，不是所有的人都可以隨意改變基線，基線也不是每時每刻不斷的變化（上篇已經介紹了版本的強制控制）。事實上，基線的變化越少越好。通�；�發生變化也存在常見的場景。
◆ 1.1版本Preview。如果1.1版本是在分支上進行開發的，那么VM希望將分支上的代碼完全合并到主分支上，以避免開發者的代碼檢入影響版本的穩定性和分支的長期存在對于版本服務器性能的影響。這種合并的工作量比較大，必須借助于一些自動合并的工具進行。
◆ 版本交替期，即1.1版本已經開始Preview但是并沒有RTM，2.0已經開始Coding。這個時候1.1版本的任何將要發布的修改都應該反映到2.0版本的初始代碼中，即使是設計的改動（最好不要有）。
◆ 補�。ò┌l布前，Bug的修改明顯將導致基線的移動。
跟版本強制控制一樣，基線的變更也是并行開發的基礎。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
