基線----所有代碼起始版本的集合

　　如果沒有并行開發(fā)，基線也許就是版本機上的一個簡單文件夾。

　　如果進行并行開發(fā)，那么基線就是具有了指定標簽的版本的集合。

　　在進行并行開發(fā)的時候，我們希望基線是流動的，會隨著我們的期望變化。比如說我們在1.1版本捉蟲的時候開始了2.0版本的開發(fā)，我們希望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文件，則除了要合并到基線中意外，還要進行上篇所介紹的的第三種場景的合并，即將基線的變化合并到已經(jīng)發(fā)生改變的2.0版本中（移動基線標簽并進行合并）。通常，基線變更涉及的文件數(shù)應該盡量少。

　　這就是流動的基線。因基線的變更需要許多人工判斷的介入，所以基線應該是穩(wěn)定經(jīng)受考驗的版本。我們要保證基線的穩(wěn)定性，不是所有的人都可以隨意改變基線，基線也不是每時每刻不斷的變化（上篇已經(jīng)介紹了版本的強制控制）。事實上，基線的變化越少越好。通?；€發(fā)生變化也存在常見的場景。

　　◆　 1.1版本Preview。如果1.1版本是在分支上進行開發(fā)的，那么VM希望將分支上的代碼完全合并到主分支上，以避免開發(fā)者的代碼檢入影響版本的穩(wěn)定性和分支的長期存在對于版本服務器性能的影響。這種合并的工作量比較大，必須借助于一些自動合并的工具進行。

　　◆　 版本交替期，即1.1版本已經(jīng)開始Preview但是并沒有RTM，2.0已經(jīng)開始Coding。這個時候1.1版本的任何將要發(fā)布的修改都應該反映到2.0版本的初始代碼中，即使是設計的改動（最好不要有）。

　　◆　 補丁（包）發(fā)布前，Bug的修改明顯將導致基線的移動。

跟版本強制控制一樣，基線的變更也是并行開發(fā)的基礎。