1) 基線：
代表多個源代碼文件的一組版本。
比如有三個文件，aaa.c、bbb.c和ccc.h。可以對這三個文件做一個基線，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一個基線。換
句話說，通常在vss和cvs里面做label，就是在做基線。
2) 基線提升：
一個文檔如果經過討論被通過了，被固定了，就可以說這個文檔被“基線化”了，然后所有人就可以在這個“基線”的基礎上工作。
當然，文檔不可能一成不變，所以當對文檔的修改仍然會不斷進行，但這種修改并不會隨時隨地的添加到被“基線化”了的文檔中去。因為既然是“基線”，就不能隨便動。
但是到了一定時候，修改積累到一定程度，就需要把很多修改合并到原來的文檔中去了，并生成一個新版本的文檔作為團隊中所有的人的參考標準，并把老的版本淘汰掉。這就叫做“基線提升”。
4）發行基線
你會對你要發行的代碼，文檔版本進行label, 比如Release2.2,
這樣，你可以隨時取出此版本作build，進行測試，發布。
5）產品基線
當發布時，你會對產品中所有的配置項進行label,包括可執行命令，文檔手冊，庫文件。。。
8) 基線(Baseline)說起. 基線是軟件文檔或源碼(或其它產出物)的一個穩定版本,它是進一步開發的基礎.所以,當基線形成后,項目負責SCM的人需要通知相關人員基線已經形成,并 且哪兒可以找到這基線了的版本.這個過程可被認為內部的發布.至于對外的正式發布,更是應當從基線了的版本中發布.
基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于此標準，并且只有經過授權后才能變更這個標準。建立一個初始基線后，以后每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。
參與項目的開發人員將基線所代表的各版本的目錄和文件填入他們的工作區。隨著工作的進展，基線將合并自從上次建立基線以來開發人員已經交付的工作。變更 一旦并入基線，開發人員就采用新的基線，以與項目中的變更保持同步。調整基線將把集成工作區中的文件并入開發工作區。
建立基線的三大原因是：重現性、可追蹤性和報告。
重現性是指及時返回并重新生成軟件系統給定發布版的能力，或者是在項目中的早些時候重新生成開發環境的能力。可追蹤性建立項目工件之間的前后繼承關系。 其目的在于確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執行文件。報告來源于一個基線內容同另一個基線內容的比較。基線比較有助于調試并生成發布 說明。
建立基線后，需要標注所有組成構件和基線，以便能夠對其進行識別和重新建立。
建立基線有以下幾個優點：
基線為開發工件提供了一個定點和快照。
新項目可以從基線提供的定點之中建立。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。
各開發人員可以將建有基線的構件作為他在隔離的私有工作區中進行更新的基礎。
當認為更新不穩定或不可信時，基線為團隊提供一種取消變更的方法。
您可以利用基線重新建立基于某個特定發布版本的配置，這樣也可以重現已報告的錯誤。
使用
定期建立基線以確保各開發人員的工作保持同步。但是，在項目過程中，應該在每次迭代結束點（次要里程碑），以及與生命周期各階段結束點相關聯的主要里程碑處定期建立基線：
生命周期目標里程碑（先啟階段）
生命周期構架里程碑（精化階段）
初始操作性能里程碑（構建階段）
產品發布里程碑（產品化階段）
區別對待缺陷和新增功能
通過進一步了解我們發現緊急的變更一般是指影響系統正常使用的軟件缺陷，這些缺陷需要及時的修 復；而新增功能請求一般不是那么緊急的，允許開發團隊有一段時間來開發實現。但開發人員目前是把所有緊急和非緊急的變更請求混雜在一起實現的，往往是一個 緊急的缺陷已經修復，但另外一個正在開發中的新增功能也修改了同一組文件版本，造成兩者之間的版本依賴，從而導致緊急的缺陷修復不能按時提交。
我們建議把缺陷的修復工作和新增功能的開發工作區分開來，這就涉及到多個版本的并行開發，開發團隊主要面臨以下三個版本的開發：
Ø v1.0中的缺陷修復
Ø v1.0的新增功能版本v1.1
Ø 下一個版本v2.0
***********************************************************************************
發布版本構建(build)而不是源代碼
這樣缺陷修復和新增功能開發相互獨立，保證緊急的缺陷修復不會受到新增功能的影響。
由于軟件構建的結果很可能會受構建平臺及相應編譯器版本所影響，最終在生產系統上的運行代碼(在生產系統上構建得到)與準生產環境上的運行代碼(在準生產環境上構建得到)可能不完全一致，有可能造成質量隱患。比較通行的做法是所有平臺上運行的構建代碼應該只在構建服務器上生成一次，一次編譯到處運行，這樣才能保證各個平臺上所用到的同版本運行代碼是同一次構建的產物。
版本發布管理
對于所發布的構建版本，我們也需要進行有序的管理，可以用版本號來唯一標識每一個發布版本。一 般可以把用于開發團隊內部系統測試的稱之為內部發布版本，把提交給客戶的稱之為外部發布版本，這兩種軟件發布版本都要統一編號管理。在我們的例子中，內部 發布版本可以簡單地用構建號來表示，如：
v1.0_build_008 表示版本v1.0開發過程中生成的第8次構建外部發布版本可以由版本號和發布號組合而成，如：
v1.0_rel01 表示版本v1.0的第一個外部發布版本
對于v1.0中的缺陷修復，我們可以通過補丁的方式來發布，一個補丁中可以包含有多個缺陷修復，被修復的缺陷需要在補丁的發布說明(Release Notes)中寫明，補丁名稱可以由版本號、發布號和補丁號組合而成，如：
v1.0_rel01_p001 表示針對發布版本v1.0_rel01的第001號補丁
對于v1.0中新增功能，我們需要制定一個發布計劃，根據客戶新增功能請求的緊急程度來分期分批實現，一次發布中可以包含多個新增功能，并且包括所有已改正的軟件缺陷，這些改動都必須在發布說明中寫明，發布版本號可以在前一個發布版本的基礎上遞增，如：
v1.1_rel02 表示版本v1.1的第二個外部發布版本
對于下一個版本v2.0的開發，則與版本v1.0開發的發布管理完全一致，如：
v2.0_build_002 表示版本v2.0開發過程中生成的第2次構建
在版本發布管理的流程中，發布版本的安裝應該由專門的角色負責，可以是配置管理員或者是集成員(integrator)；開發人員被禁止向各平臺（測試平臺、準生產環境、生產系統）上安裝任何軟件，并且各平臺上所安裝軟件的版本號.0.0 Notes 11都應該有詳細的記錄。當軟件缺陷被發現時，我們就可以明確知道問題究竟是出在哪一個版本。
內部發布版本只會被安裝到測試平臺上，經過 “開發 à 構建 à 測試 à 發現缺陷à 修改代碼” 的多次循環之后，內部發布版本的質量趨于穩定，開發團隊才會決定做一個外部發布版本。
外部發布版本被安裝到準生產環境上，并且只有通過用戶驗收測試，它才可以被安裝到生產系統上 去。如果該版本沒有通過用戶驗收測試，那么開發團隊需要提供相應的補丁來解決用戶驗收中發現的問題，直到通過用戶驗收后再將該發布版本及其所有的累積補丁 全部安裝到生產系統上去。有些情況下，最終通過驗收測試的也可能是下一個發布版本，所以生產系統上安裝的發布版本前后之間不一定是連續的，中間可能跳過一 些質量不夠成熟的版本。
同樣的，只有通過用戶驗收測試的補丁才會被最終安裝到生產系統上去。緊急的補丁經過用戶驗收測試之后會馬上安裝到生產系統上，不緊急的補丁可以累積幾個以后批量安裝上去。