我知道版本控制系統（VCS）很有用。
但是，我平時(shí)只是業(yè)余寫(xiě)一些小程序，感覺(jué)特地裝一個(gè)VCS太麻煩，所以一直沒(méi)有用。最近，因為想認真做一個(gè)中等規模的項目，所以決心好好學(xué)一下怎么用。
下面就是我翻譯的一篇入門(mén)教程，主要解釋了VCS的一些主要概念。
======================
A Visual Guide to Version Control
版本控制入門(mén)插圖教程
作者：Kalid Azad
譯者：阮一峰
原文網(wǎng)址：http://betterexplained.com/articles/a-visual-guide-to-version-control/
版本控制（Version Control）的作用是追蹤文件的變化。為什么需要版本控制？簡(jiǎn)單說(shuō)，就是當你出錯了，可以很容易地回到?jīng)]出錯時(shí)的狀態(tài)。
你可能已經(jīng)在不知不覺(jué)中，布置了自己的版本控制系統。比如，創(chuàng )建了類(lèi)似下面這樣的文件名：
* KalidAzadResumeOct2006.doc
* KalidAzadResumeMar2007.doc
* instacalc-logo3.png
* instacalc-logo4.png
* logo-old.png
這就是軟件中為什么有"Save As"命令的原因。它使得你可以在不破壞源文件的基礎上，得到一個(gè)類(lèi)似的新文件。文件的多版本保存是一個(gè)常見(jiàn)問(wèn)題，通常的解決辦法是這樣的：
* 做一個(gè)文件備份（比如Document.old.txt）。
* 在文件名中加入版本號或日期（比如Document_V1.txt，DocumentMarch2007.txt）。
* 在多人編輯的環(huán)境下，共享一個(gè)文件目錄，并且要求每個(gè)人編輯完以后，在文件上做出標識。
什么是版本控制系統（VCS）？
通過(guò)文件名識別版本，對于小型項目或者單個(gè)文件也許可行。但是對于軟件開(kāi)發(fā)來(lái)說(shuō)，是不適用的。
你能想像嗎，要是Windows操作系統的源文件，是在一個(gè)叫做"Windows2007-Latest-UPDATED!!"的共享目錄中開(kāi)發(fā)的，并且每個(gè)程序員都可以編輯，都有一個(gè)自己的子目錄，那會(huì )發(fā)生什么情況？那么，Windows就根本不可能被制造出來(lái)。
大型的、頻繁修改的、多人編寫(xiě)的軟件項目，需要一個(gè)版本控制系統（簡(jiǎn)稱(chēng)VCS，行話(huà)叫做"文件數據庫"），追蹤文件的變化，避免出現混亂。一個(gè)好的VCS應該做到以下幾點(diǎn)：
* 備份（Backup）和恢復（Restore）。文件的每一次編輯都得到保存，可以恢復到任意一個(gè)日期。需要2007年2月23日的版本？沒(méi)問(wèn)題。
* 同步（Synchronization）。讓不同用戶(hù)隨時(shí)都能得到文件的最新版本。
* 短期撤銷(xiāo)（Short-term undo）。文件被你搞亂了，怎么辦？那就撤銷(xiāo)編輯，回到最近一次的無(wú)差錯版本。
* 長(cháng)期撤銷(xiāo)（Long-term undo）。有時(shí)候，你會(huì )過(guò)了很久才發(fā)現出錯了。如果你想撤銷(xiāo)一年前的一次編輯，怎么辦？那就去取回一年之前的那個(gè)版本。
* 追蹤修改（Track Changes）。文件的每一次編輯，你都可以寫(xiě)下注解，解釋編輯的原因。（這些信息儲存在VCS中，而不是文件中。）這樣就很容易看出，長(cháng)期中文件變化的脈絡(luò )和原因。
* 追蹤權限（Track Ownership）。VCS會(huì )記錄每一次提交新版本的用戶(hù)名。這樣就容易追蹤責任。
* 試驗功能（Sandboxing）。當你對文件做出重大變更時(shí)，你可以把編輯內容暫時(shí)性地保存在一個(gè)單獨的區域，不斷進(jìn)行測試和除錯。等到確認正確以后，再加入主版本。
* 分支（Branching）和合并（merging）。分支功能可以看成是一個(gè)更大的測試版本。你將整個(gè)的代碼做一份拷貝，然后再起一個(gè)獨立的名字，追蹤其變化，與原版本脫離關(guān)系，這就是分支。以后，你還可以將分支版本再并入源版本，這就是合并。
雖然共享文件夾操作起來(lái)更快速和簡(jiǎn)單，但是它做不到上面這些功能。
一些術(shù)語(yǔ)
大多數VCS都有下面一些共同的概念，不過(guò)名字可能會(huì )稍有不同。
基本概念
* Repository (repo): 儲存文件的數據庫。
* Server: 儲存repo的計算機。
* Client: 連接repo的計算機。
* Working Set/Working Copy: 當你編輯文件時(shí)，編輯對象所在的本地文件目錄。
* Trunk/Main: repo中儲存代碼文件的主位置。你可以把代碼想像成一棵家族樹(shù)，“trunk”就是主線(xiàn)的那條樹(shù)干。
基本操作
* Add: 將一個(gè)文件第一次加入repo，也就是開(kāi)始用VCS追蹤這個(gè)文件。
* Revision: 文件的版本編號（即v1, v2, v3等等）。
* Head: repo中保存的文件最新版本。
* Check out：從repo中下載一個(gè)文件。
* Check in: 上傳文件進(jìn)入repo（如果文件發(fā)生了變化）。這個(gè)文件將得到一個(gè)新的版本編號，用戶(hù)將可以“check out”這個(gè)文件。
* Checkin Message: 描述所做修改的短說(shuō)明。
* Changelog/History: 一個(gè)記錄文件自從創(chuàng )建開(kāi)始所有變動(dòng)的清單。
* Update/Sync: 將你本地的文件同repo中最新版本進(jìn)行同步的過(guò)程。這將使得本地文件始終能夠跟上最新的變動(dòng)。
* Revert: 放棄對文件所做的編輯，從repo中重新獲得未編輯前的版本。
高級操作
* Branch: 在repo中對一個(gè)文件或文件目錄，創(chuàng )建一個(gè)獨立的拷貝。Branch在這里既是動(dòng)詞（branch the code），又是名詞（Which branch is it in?）。
* Diff/Change/Delta: 找出兩個(gè)文件之間的差別。對于比較不同版本之間的變動(dòng)很有用。
* Merge (or patch): 將一個(gè)文件上的改動(dòng)，應用于另一個(gè)文件，使得兩者保持相同。比如，你可以將一個(gè)branch中的功能merge到另一個(gè)branch中。
* Conflict: 當你check in的時(shí)候，你所做的變動(dòng)可能與其他用戶(hù)發(fā)生沖突。（這時(shí)雙方的編輯都不會(huì )生效。）
* Resolve: 修改互相沖突的變動(dòng)，check in正確的版本。
* Locking: 取得一個(gè)文件的“控制權”，使得在你解鎖之前，其他人不能編輯這個(gè)文件。有些VCS用這個(gè)功能避免conflict。
* Breaking the lock: 強制解鎖一個(gè)文件，使得你可以對其進(jìn)行編輯。比如，某人lock了一個(gè)文件，但是他又去度假了。
* Check out for edit: Check out到一個(gè)文件“可編輯”的版本。有些VCS默認允許編輯，另一些要求明確發(fā)出命令后，才提供可編輯的版本。
一次典型的使用過(guò)程是這樣的：
愛(ài)麗絲add一個(gè)文件（list.txt）進(jìn)入repo。然后，她又把這個(gè)文件check out，做了一次編輯（在文件中加入milk這個(gè)單詞）。接著(zhù)，她將修改后的文件check in，并附有一條checking message（“加入了新的條目”）。第二天早上，鮑勃update了他本地的working set，看到了list.txt的最新修訂版，其中包含了單詞“milk”。如果他使用changelog或diff，都可以發(fā)現前一天愛(ài)麗絲加入“milk”這個(gè)詞。
下面，我們用一些例子，來(lái)講解VCS的使用。
Check in
最簡(jiǎn)單的情況是，check in一個(gè)文件（list.txt），然后經(jīng)常修改它。
在subversion系統中的命令是：
svn add list.txt
(modify the file)
svn ci list.txt -m "Changed the list"
最后一個(gè)命令中的-m標識，表示check in時(shí)附帶的message。
Check out和編輯
你不一定總是Check in文件，有時(shí)候你需要check out，進(jìn)行編輯，然后再check in。這個(gè)過(guò)程可以用下圖表示：
如果你對自己的編輯不滿(mǎn)意，想要從頭開(kāi)始，你可以revert到上一個(gè)版本。當你check out的時(shí)候，默認情況下，你總是會(huì )得到最新版本。如果你想得到以前的版本，你可以在命令中指定版本號。在Subversion中，運行下面的命令：
svn co list.txt (get latest version)
...edit file...
svn revert list.txt (throw away changes)svn co -r2 list.txt (check out particular version)
Diff
Diff就是你編輯時(shí)所做的變動(dòng)。你可以想象一下，單獨將變動(dòng)部分保存下來(lái)，然后將它們應用到一個(gè)文件上：
比如，從r1版到r2版，我們加入eggs（+Eggs）。你可以將這個(gè)過(guò)程想象成，單獨將圖中紅色的部分保存下來(lái)，然后將它應用到r1上，就可以得到r2。
從r2版到r3版，我們加入了Juice（+Juice）。從r3版到r4版，我們刪去了Juice加入了Soup（-Juice, +Soup）。
大多數版本控制系統，只保存diff，而不是文件的完整版本。這樣可以節省磁盤(pán)空間。你做了4次修改，不意味著(zhù)系統保留了4份拷貝。實(shí)際上，系統內只有1份拷貝和4個(gè)diff。在SVN中，我們用下面的命令diff一個(gè)文件的兩個(gè)版本：
svn diff -r3:4 list.txt
Branch
Branch可以將源文件做一份拷貝，保存在VCS的另一個(gè)位置，然后我們對拷貝進(jìn)行修改，不會(huì )影響到源文件。
比如，上圖中我們創(chuàng )建了一個(gè)branch，在其中加入了Rice，而在trunk上加入的是Bread。有的VCS在創(chuàng )建Branch時(shí)，可能會(huì )修改版本號。
在Subversion中，創(chuàng )建branch的命令很簡(jiǎn)單，只要從一個(gè)目錄拷貝到另一個(gè)目錄就可以了。
svn copy http://path/to/trunk http://path/to/branch
所以，branch并不難理解，你只要想像將代碼拷貝到不同目錄就行了。它的好處在于，不管你做錯了什么，你總可以回到一個(gè)安全的版本。
Merge
如果你要將一個(gè)branch中的變動(dòng)，并入另一個(gè)branch，這可不太簡(jiǎn)單。
比如，我們要將Rice這個(gè)詞從一個(gè)branch，并入主線(xiàn)中的文件。我們應該怎么做？Diff一下r6和r7，然后再并入主線(xiàn)？
錯了。我們只需要找到branch所做的變動(dòng)就可以了。也就是說(shuō)，我們只要diff一下r5和r6，然后再應用到trunk上就可以了。
如果我們diff了r6和r7，我們就會(huì )漏掉“Bread”這個(gè)已經(jīng)在主干中的詞。這是很微妙的一個(gè)地方，branch中的變動(dòng)在于Rice這個(gè)詞（+Rice），只要將這個(gè)詞加入主干就可以了。主干文件中也許還有其他變化，不過(guò)這不要緊，我們所要的只是插入Rice這個(gè)特性。
在Subversion中，merge命令與diff很類(lèi)似。在一個(gè)主干中，運行下面的命令：
svn merge -r5:6 http://path/to/branch
這個(gè)命令diff了r5和r6，然后將其加入當前位置的文件中。不幸的是，Subversion沒(méi)有提供一種容易的途徑，追蹤merge中到底有什么變動(dòng)。所以如果你不小心的話(huà)，你可能將同樣的變動(dòng)應用兩次。SVN已經(jīng)計劃提供這個(gè)功能，但是目前的建議還是，保留一份changelog message，提醒你r5-r6已經(jīng)并入了主干。
Conflict
Conflict往往來(lái)自不同用戶(hù)，同時(shí)對同一個(gè)內容做出了不同的修改。Joe想刪除eggs，加入cheese（-eggs, +cheese），Sue想刪除eggs，加入hot dog（-eggs, +hot dog）。
從某個(gè)角度看，這有點(diǎn)像一場(chǎng)比賽：如果Joe首先check in，那么他的編輯將寫(xiě)入文件。（Sue的編輯將被拒絕。）
如果他們同時(shí)提交了這種互相沖突的變動(dòng)，VCS將報告一個(gè)conflict，不允許check in。由你來(lái)決定，是check in一個(gè)更新的版本，還是就地解決這個(gè)沖突。下面是一些可能的辦法：
* 重做一遍編輯。首先，將文件Sync到最新的版本（r4），這時(shí)cheese已經(jīng)在文件中了。你再重做一遍剪輯，加上hot dog。
* 覆蓋掉他人的修改。將文件check out到最新的版本（r4），用你的版本將這個(gè)版本覆蓋，再check in。也就是說(shuō)，你等于刪掉了cheese，替換為hot dog。
Conflict不是很常見(jiàn)，但是處理起來(lái)很麻煩。通常，我會(huì )選擇上面第一種處理方法。
Tag
大概不會(huì )有人想到VCS早就符合Web 2.0的潮流吧？許多VCS允許你對任意編輯做一個(gè)標簽（label），方便以后的引用。這樣一來(lái)，你就可以用“Release 1.0”，指代內部的版本號碼。
在Subversion中，tag其實(shí)是不再讓你編輯的branche，它們只是方便為了以后的使用，讓你能夠明確看到1.0版中到底包含了哪些東西。因此它們就停頓在那里，不再變動(dòng)了。
(in trunk)
svn copy http://path/to/revision http://path/to/tag
一個(gè)實(shí)際的例子：管理Windows源碼
我們前面說(shuō)過(guò)，微軟公司不用共享文件夾管理代碼，那么他們怎么管理呢？
* 首先有一條main line，專(zhuān)門(mén)保存穩定版本的Windows。
* 然后，每個(gè)開(kāi)發(fā)小組（網(wǎng)絡(luò )、用戶(hù)界面、媒體播放器等等）都有各自的branch，來(lái)添加新功能。這些新功能還在開(kāi)發(fā)當中，并不穩定。
你在你的branch中，開(kāi)發(fā)了一個(gè)新功能。然后，你用“Reverse Integrate (RI)”，將它并入主版本。接著(zhù)，你再用“Forward Integrate”，你再去得到最新的主版本，將它并入你的branch。
假設老版本是Media Player 10和IE 6。Media Player開(kāi)發(fā)小組，在他們的branch中制作了第11版，然后他們用一個(gè)10 - 11的補丁，將第11版加入老版本中。這是一個(gè)reverse integration，從branch到trunk。IE開(kāi)發(fā)小組也是同樣的步驟。
接著(zhù)，Media Player開(kāi)發(fā)小組從其他小組（比如IE小組）得到最新的代碼。在這個(gè)例子中，Media Player從trunk得到最新的補丁，運用到他們的branch中，這叫做forward integration。
reverse integration和forward integration，分別簡(jiǎn)稱(chēng)RI和FI。這樣的安排讓變動(dòng)主要在branch中發(fā)生，而使得主干保持相對不受影響。
在微軟實(shí)際運作中，有很多層的branch和sub-branch，還有許多質(zhì)量控制標準，確定什么時(shí)候才可以進(jìn)行RI。這里只是希望幫助你建立一個(gè)想法，那就是branch有助于管理復雜的項目?，F在，你應該明白了世界上最大的軟件項目之一，是怎么進(jìn)行組織的。
結束語(yǔ)
如果你以前沒(méi)有用過(guò)VCS，我建議你使用它。因為它是一種很好的工具，即使你不打算寫(xiě)一個(gè)操作系統，單單就是為了備份，也值得用它。
網(wǎng)上有許多VCS軟件可供選擇，并且都有詳細的教程或手冊，比如SVN、CVS、RCS、Git、Perforce等等。Eric Sink寫(xiě)過(guò)一個(gè)詳細的version control guide可供參考。
（完）
