Pro Git 1.1 關於版本控制 - 修訂歷史

imported>Ray 於 2011年5月24日 (二) 04:02

2011-05-24T04:02:27Z

←上個修訂		於 2011年5月24日 (二) 12:02 的修訂
行 2：		行 2：

	如果你是位元圖形或網頁設計師，可能會需要保存某一幅圖片或頁面配置檔的所有修訂版本。採用版本控制系統（VCS）是個明智的選擇。有了它你就可以將某個檔回溯到之前的狀態，甚至將整個專案都回退到過去某個時間點的狀態。你可以比較檔的變化細節，查出是誰最後修改了什麼地方從而造成某些怪異問題，又是誰在何時報告了某個功能缺陷，等等。使用版本控制系統通常還意味著，就算你胡來搞砸了整個專案，把檔改的改，刪的刪，你也可以輕鬆恢復到原先的樣子。而由此額外增加的工作量卻微乎其微。		如果你是位元圖形或網頁設計師，可能會需要保存某一幅圖片或頁面配置檔的所有修訂版本。採用版本控制系統（VCS）是個明智的選擇。有了它你就可以將某個檔回溯到之前的狀態，甚至將整個專案都回退到過去某個時間點的狀態。你可以比較檔的變化細節，查出是誰最後修改了什麼地方從而造成某些怪異問題，又是誰在何時報告了某個功能缺陷，等等。使用版本控制系統通常還意味著，就算你胡來搞砸了整個專案，把檔改的改，刪的刪，你也可以輕鬆恢復到原先的樣子。而由此額外增加的工作量卻微乎其微。

	=本地版本控制系统=		== 本地版本控制系统 ==
	許多人習慣用複製整個專案目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單，不過壞處卻不少：有時候會混淆所在的工作目錄，弄錯了檔丟了資料就沒了後退的路。		許多人習慣用複製整個專案目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單，不過壞處卻不少：有時候會混淆所在的工作目錄，弄錯了檔丟了資料就沒了後退的路。

行 13：		行 13：
	其中最流行的一種叫做 rcs，現今許多電腦系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 命令。它的工作原理基本上就是保存並管理文件補丁（patch）。檔補丁是一種特定格式的文字檔，記錄著對應檔修訂前後的內容變化。所以，根據每次修訂後的補丁，rcs 可以通過不斷打補丁，計算出各個版本的檔內容。		其中最流行的一種叫做 rcs，現今許多電腦系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 命令。它的工作原理基本上就是保存並管理文件補丁（patch）。檔補丁是一種特定格式的文字檔，記錄著對應檔修訂前後的內容變化。所以，根據每次修訂後的補丁，rcs 可以通過不斷打補丁，計算出各個版本的檔內容。

	=集中化的版本控制系统=		==集中化的版本控制系统==
	接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的伺服器，保存所有檔的修訂版本，而協同工作的人們都通過用戶端連到這台伺服器，取出最新的檔或者提交更新。多年以來，這已成為版本控制系統的標準做法（見圖 1-2）。		接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的伺服器，保存所有檔的修訂版本，而協同工作的人們都通過用戶端連到這台伺服器，取出最新的檔或者提交更新。多年以來，這已成為版本控制系統的標準做法（見圖 1-2）。

行 22：		行 22：
	事分兩面，有好有壞。這麼做最顯而易見的<b>缺點</b>是<b>中央伺服器的單點故障</b>。若是宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。如果中央伺服器的磁片發生故障，並且沒做過備份或者備份得不夠及時的話，還會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄，被用戶端提取出來的某些快照資料除外，但這樣的話依然是個問題，你不能保證所有的資料都已經有人提取出來。本地版本控制系統也存在類似問題，只要整個專案的歷史記錄被保存在單一位置，就有丟失所有歷史更新資訊的風險。		事分兩面，有好有壞。這麼做最顯而易見的<b>缺點</b>是<b>中央伺服器的單點故障</b>。若是宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。如果中央伺服器的磁片發生故障，並且沒做過備份或者備份得不夠及時的話，還會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄，被用戶端提取出來的某些快照資料除外，但這樣的話依然是個問題，你不能保證所有的資料都已經有人提取出來。本地版本控制系統也存在類似問題，只要整個專案的歷史記錄被保存在單一位置，就有丟失所有歷史更新資訊的風險。

	=分散式版本控制系統=		==分散式版本控制系統==

	於是分散式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，諸如 Git，Mercurial，Bazaar 還有 Darcs 等，用戶端並不只提取最新版本的檔快照，而是把原始的代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份（見圖 1-3）。		於是分散式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，諸如 Git，Mercurial，Bazaar 還有 Darcs 等，用戶端並不只提取最新版本的檔快照，而是把原始的代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份（見圖 1-3）。

imported>Ray：新頁面: 什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，...

2011-05-24T03:57:57Z

新頁面: 什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，...

新頁面

什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，我們僅對保存著軟體原始程式碼的文字檔作版本控制管理，而實際上，你可以對任何類型的檔進行版本控制。

如果你是位元圖形或網頁設計師，可能會需要保存某一幅圖片或頁面配置檔的所有修訂版本。採用版本控制系統（VCS）是個明智的選擇。有了它你就可以將某個檔回溯到之前的狀態，甚至將整個專案都回退到過去某個時間點的狀態。你可以比較檔的變化細節，查出是誰最後修改了什麼地方從而造成某些怪異問題，又是誰在何時報告了某個功能缺陷，等等。使用版本控制系統通常還意味著，就算你胡來搞砸了整個專案，把檔改的改，刪的刪，你也可以輕鬆恢復到原先的樣子。而由此額外增加的工作量卻微乎其微。

=本地版本控制系统=
許多人習慣用複製整個專案目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單，不過壞處卻不少：有時候會混淆所在的工作目錄，弄錯了檔丟了資料就沒了後退的路。

為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的資料庫來記錄檔的歷次更新差異（見圖 1-1）。

[[圖片:Pro-git-1-1.png‎]]
圖 1-1. 本地版本控制系統

其中最流行的一種叫做 rcs，現今許多電腦系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 命令。它的工作原理基本上就是保存並管理文件補丁（patch）。檔補丁是一種特定格式的文字檔，記錄著對應檔修訂前後的內容變化。所以，根據每次修訂後的補丁，rcs 可以通過不斷打補丁，計算出各個版本的檔內容。

=集中化的版本控制系统=
接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的伺服器，保存所有檔的修訂版本，而協同工作的人們都通過用戶端連到這台伺服器，取出最新的檔或者提交更新。多年以來，這已成為版本控制系統的標準做法（見圖 1-2）。

[[圖片:Pro-git-1-2.png‎]]

這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。現在，每個人都可以一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕鬆掌控每個開發者的許可權，並且管理一個 CVCS 要遠比在各個用戶端上維護本地資料庫輕鬆容易得多。

事分兩面，有好有壞。這麼做最顯而易見的<b>缺點</b>是<b>中央伺服器的單點故障</b>。若是宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。如果中央伺服器的磁片發生故障，並且沒做過備份或者備份得不夠及時的話，還會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄，被用戶端提取出來的某些快照資料除外，但這樣的話依然是個問題，你不能保證所有的資料都已經有人提取出來。本地版本控制系統也存在類似問題，只要整個專案的歷史記錄被保存在單一位置，就有丟失所有歷史更新資訊的風險。

=分散式版本控制系統=

於是分散式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，諸如 Git，Mercurial，Bazaar 還有 Darcs 等，用戶端並不只提取最新版本的檔快照，而是把原始的代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份（見圖 1-3）。

[[圖片:Pro-git-1-3.png‎]]
圖 1-3. 分散式版本控制系統

更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個專案中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程，比方說層次模型式的工作流，這在以前的集中式系統中是無法實現的。

Pro Git 1.1 關於版本控制 - 修訂歷史

imported>Ray 於 2011年5月24日 (二) 04:02

imported>Ray：​新頁面: 什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，...

imported>Ray：新頁面: 什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，...