軟體工程/工具/原始碼控制簡介

版本控制專案的示例歷史樹。

版本控制，也稱為版本控制或原始碼控制（以及軟體配置管理或SCM的一個方面），是對儲存為計算機檔案的文件、程式和其他資訊更改的管理。它最常用於軟體開發，其中一個團隊的人員可能會更改相同的檔案。更改通常由一個數字或字母程式碼標識，稱為“版本號”、“版本級別”或簡稱“版本”。例如，一組初始檔案是“版本 1”。當進行第一次更改時，結果集是“版本 2”，依此類推。每次修訂都與時間戳和進行更改的人員相關聯。修訂可以進行比較、恢復，並且在某些型別的檔案的情況下可以進行合併。

版本控制系統（VCS – 單數 VCS）最常作為獨立應用程式執行，但版本控制也嵌入在各種型別的軟體中，例如文字處理器（例如，Microsoft Word、OpenOffice.org Writer、KWord、Pages 等）、電子表格（例如，Microsoft Excel、OpenOffice.org Calc、KSpread、Numbers 等）以及各種內容管理系統（例如，Drupal、Joomla、WordPress）。整合版本控制是維基軟體包（如 MediaWiki、DokuWiki、TWiki 等）的關鍵功能。在維基中，版本控制允許將頁面恢復到以前版本，這對於允許編輯者跟蹤彼此的編輯、更正錯誤以及保護公共維基免受破壞和垃圾郵件至關重要。

版本控制軟體工具對於組織多開發人員專案至關重要。

概述

版本控制源於基於早期藍圖或藍線的修訂跟蹤的正式流程。這種控制系統隱式地允許返回到設計的任何早期狀態，以防在設計開發過程中遇到工程死衚衕。同樣，在計算機軟體工程中，版本控制是任何跟蹤和控制原始碼更改的實踐。軟體開發人員有時使用版本控制軟體來維護文件和配置檔案以及原始碼。此外，版本控制在商業和法律領域也十分普遍。“合同紅線”和“法律黑線”是版本控制的最早形式之一，並且仍在不同程度的複雜性中使用。整個行業已經出現，以滿足商業和其他使用者的文件版本控制需求，並且這些領域中使用的一些版本控制技術是微妙、強大和創新的。最複雜的技術開始用於電子跟蹤 CAD 檔案的更改（參見產品資料管理），取代了傳統版本控制的“手動”電子實現。

隨著團隊設計、開發和部署軟體，同一個軟體的多個版本經常部署在不同的站點，並且軟體的開發人員可能同時進行更新。軟體的錯誤或功能通常只存在於某些版本中（因為隨著程式的開發，一些問題被修復，而另一些問題被引入）。因此，為了定位和修復錯誤，能夠檢索和執行軟體的不同版本以確定問題發生在哪些版本中至關重要。可能還需要同時開發兩個版本的軟體（例如，一個版本修復了錯誤，但沒有新功能（分支），而另一個版本是開發新功能的地方（主幹）。

在最簡單的層面上，開發人員可以簡單地保留程式不同版本的多個副本，並對其進行適當的標記。這種簡單的方法已用於許多大型軟體專案。雖然這種方法可以工作，但它效率低下，因為必須維護程式的許多幾乎相同的副本。這需要開發人員付出很多自律，並且經常導致錯誤。因此，已經開發出用於自動化部分或全部版本控制流程的系統。

此外，在軟體開發、法律和商業實踐以及其他環境中，一個團隊對單個文件或程式碼片段進行編輯變得越來越普遍，團隊成員可能分散在地域上，並且可能追求不同甚至相反的利益。在這些情況下，跟蹤和記錄文件和程式碼更改的所有權的複雜版本控制可能非常有用甚至必要。

版本控制還可以跟蹤對配置檔案的更改，例如通常儲存在 Unix 系統上的/etc或/usr/local/etc中的配置檔案。這為系統管理員提供了一種輕鬆跟蹤所做更改的方法，以及在需要時回滾到早期版本的方法。

原始碼管理模型

傳統的版本控制系統使用集中式模型，所有版本控制功能都在共享伺服器上進行。如果兩個開發人員嘗試同時更改同一個檔案，如果沒有某種方法來管理訪問許可權，開發人員最終可能會覆蓋彼此的工作。集中式版本控制系統透過兩種不同的“原始碼管理模型”之一來解決此問題：檔案鎖定和版本合併。

原子操作

計算機科學家談到原子操作，如果即使操作被中斷，系統也處於一致狀態。從這個意義上說，提交操作通常是最關鍵的。提交是告訴版本控制系統您要將您一直在進行的一組更改最終確定並提供給所有使用者的操作。並非所有版本控制系統都有原子提交；值得注意的是，廣泛使用的 CVS 缺少此功能。

檔案鎖定

防止“併發訪問”問題的最簡單方法是鎖定檔案，以便一次只有一個開發人員可以寫入這些檔案的中央“儲存庫”副本。一旦一個開發人員“檢出”一個檔案，其他人可以讀取該檔案，但沒有人可以更改該檔案，直到該開發人員“檢入”更新的版本（或取消檢出）。

檔案鎖定既有優點也有缺點。當用戶對大型檔案（或一組檔案）的許多部分進行根本性更改時，它可以提供一些防止難以合併衝突的保護。但是，如果檔案被長期獨佔鎖定，其他開發人員可能會想繞過版本控制軟體並在本地更改檔案，從而導致更嚴重的問題。

實驗

版本合併

大多數版本控制系統允許多個開發人員同時編輯同一個檔案。第一個“檢入”對中央儲存庫更改的開發人員始終成功。系統可以提供將進一步的更改合併到中央儲存庫的功能，並在其他開發人員檢入時保留第一個開發人員的更改。

合併兩個檔案可能是一個非常微妙的操作，通常只有在資料結構簡單的情況下才有可能，例如文字檔案。合併兩個影像檔案的結果可能根本不會生成影像檔案。第二個檢查程式碼的開發人員需要小心合併，以確保更改相容，並且合併操作不會在檔案內部引入自己的邏輯錯誤。這些問題限制了自動或半自動合併操作的可用性，主要限於簡單的基於文字的文件，除非該檔案型別有特定的合併外掛可用。

保留編輯的概念可以提供一種可選的方法，即使在存在合併功能的情況下，也可以明確地鎖定檔案以供獨佔寫入訪問。

基線、標籤和標記

大多數版本控制工具只使用這些類似術語之一（基線、標籤、標記）來指代標識快照（“標記專案”）或快照記錄（“使用基線X嘗試它”）的操作。通常在文件或討論中只使用基線、標籤或標記術語之一；它們可以被認為是同義詞。

在大多數專案中，一些快照比其他快照更重要，例如那些用於指示釋出版本、分支或里程碑的快照。

當基線術語與標籤或標記中的任何一個同時使用時，標籤和標記通常指代工具中標識或建立快照記錄的機制，而基線則表示任何給定標籤或標記的重要意義。

大多數關於配置管理的正式討論都使用基線術語。

分散式版本控制

分散式版本控制 (DRCS) 採用點對點方法，而不是集中式系統的客戶端-伺服器方法。每個對等方的工作副本不是與單個集中式儲存庫同步的客戶端，而是程式碼庫的真正儲存庫。 分散式版本控制透過在對等方之間交換補丁（變更集）來進行同步。這導致了一些與集中式系統的重要區別

• 預設情況下，不存在規範的程式碼庫參考副本；只有工作副本。
• 常見操作（如提交、檢視歷史記錄和恢復更改）速度很快，因為不需要與中央伺服器通訊。

相反，只有在將更改推送到其他對等方或從其他對等方拉取更改時才需要通訊。

• 每個工作副本實際上都充當程式碼庫及其更改歷史記錄的遠端備份，從而提供了針對資料丟失的自然保護。

整合

一些更高階的版本控制工具提供了許多其他功能，允許與其他工具和軟體工程流程更深入地整合。通常有針對 Oracle JDeveloper、IntelliJ IDEA、Eclipse 和 Visual Studio 等 IDE 的外掛可用。NetBeans IDE 和 Xcode 帶有整合的版本控制支援。

通用詞彙

術語可能因系統而異，但一些常用術語包括：

基線

文件或原始檔的已批准修訂，可以從中進行後續更改。請參閱基線、標籤和標記。

分支

在版本控制下的檔案集可以在某個時間點被分支或分叉，以便從該時間點起，這兩個檔案的副本可以以不同的速度或以不同的方式獨立於彼此地發展。

更改

更改（或差異或增量）表示對版本控制下的文件的特定修改。被視為更改的修改的粒度在版本控制系統之間有所不同。

變更列表

在許多具有原子多更改提交的版本控制系統中，變更列表、變更集或補丁標識在單個提交中進行的一組更改。這也可以表示原始碼的順序檢視，允許檢查“截至”任何特定變更列表 ID 的原始碼。

檢出

檢出（或co）是從儲存庫建立本地工作副本的行為。使用者可以指定特定修訂版或獲取最新修訂版。術語“檢出”也可以用作名詞來描述工作副本。

提交

提交（簽入、ci或更罕見的是安裝、提交或記錄）是將工作副本中所做的更改寫入或合併回儲存庫的操作。術語“提交”和“簽入”也可以用作名詞來描述作為提交結果而建立的新修訂版。

衝突

當不同的參與者對同一個文件進行更改時，並且系統無法協調這些更改時，就會發生衝突。使用者必須透過合併更改或選擇一個更改以支援另一個更改來解決衝突。

增量壓縮

大多數版本控制軟體使用增量壓縮，它只保留檔案連續版本之間的差異。這允許更有效地儲存檔案的許多不同版本。

動態流

某些或所有檔案版本是父流版本映象的流。

匯出

匯出是從儲存庫獲取檔案的行為。它類似於檢出，但它建立一個乾淨的目錄樹，沒有工作副本中使用的版本控制元資料。例如，這通常在釋出內容之前使用。

頭部

有時也稱為頂端，它指的是最新的提交。

匯入

匯入是將本地目錄樹（當前不是工作副本）首次複製到儲存庫中的行為。

標籤

請參閱標記。

主線

類似於主幹，但每個分支都可以有一個主線。

合併

合併或整合是將兩組更改應用於檔案或一組檔案的操作。以下是一些示例場景

• 使用者在處理一組檔案時，更新或同步其工作副本，以獲取其他使用者所做的更改並簽入到儲存庫中。

• 使用者嘗試簽入自檔案被檢出以來被其他人更新的檔案，並且版本控制軟體自動合併這些檔案（通常，在提示使用者是否應繼續進行自動合併後，並且在某些情況下，只有在合併能夠清晰且合理地解決時才這樣做）。
• 一組檔案被分支，在分支之前存在的問題在一個分支中得到修復，然後將修復合併到另一個分支中。
• 建立一個分支，對檔案中的程式碼進行獨立編輯，然後將更新的分支合併到一個統一的主幹中。

提升

將檔案內容從控制程度較低的 location 複製到控制程度較高的 location 的行為。例如，從使用者的 workspace 複製到儲存庫，或從一個流複製到其父流。

儲存庫

儲存庫是儲存檔案當前和歷史資料的位置，通常位於伺服器上。有時也稱為庫（例如，由 SVK、AccuRev 和 Perforce 稱謂）。

解決

使用者干預以解決對同一個文件的不同更改之間的衝突的行為。

反向整合

將不同的團隊分支合併到版本控制系統主幹的過程。

修訂版

也稱為版本：版本是形式的任何更改。在 SVK 中，修訂版是指儲存庫中整個樹在某個時間點的狀態。

環

請參閱標記。

共享

使一個檔案或資料夾同時在多個分支中可用的行為。當在某個分支中更改共享檔案時，它也會在其他分支中更改。

流

一個用於分支檔案的容器，它與其他此類容器有已知的關聯。流形成一個層次結構；每個流都可以從其父流繼承各種屬性（如版本、名稱空間、工作流規則、訂閱者等）。

標籤

一個標籤或標記指的是時間上的一個重要快照，在許多檔案之間保持一致。這些檔案在那個時間點可能會被標記上一個使用者友好的、有意義的名稱或修訂號。請參見基線、標籤和標記。

主幹

唯一的開發路線，不是分支（有時也稱為基線或主線）。

更新

一個更新（或同步）將儲存庫中所做的更改（例如，由其他人完成）合併到本地工作副本中。^[6]

工作副本

工作副本是儲存庫中檔案的本地副本，在特定時間或修訂版。對儲存庫中檔案的所有工作最初都在工作副本上進行，因此得名。從概念上講，它是一個沙箱。

外部連結

• Eric Sink 的版本控制 HOWTO 版本控制基礎知識入門
• 版本控制視覺指南
• Better SCM Initiative: 比較 對不同系統及其功能的有用總結。