Git 🌙
Chapters ▾ 2nd Edition

1.1 開始 - 關於版本控制

本章將介紹 Git 的相關知識。首先將從版本控制工具的背景知識開始，接著是如何在你的系統上運作 Git，而最後則是如何設定它。 閱讀完本章後你應該可以了解為什麼 Git 如此流行、為何你應該使用它，並完成準備工作。

關於版本控制

什麼是「版本控制」？ 我為什麼要關心它呢？ 版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。 在本書的範例中，你將會學到如何對軟體的原始碼做版本控制。當然，你實際上可以對電腦上任意型態的檔案做版本控制。

如果您是美術設計或是網頁設計師，你可能會想要記錄每一次對影像或版面配置的修改（這也通常是你最想要的功能），採用版本控制系統（VCS）就是明智之選。 它允許你將檔案復原到之前的狀態、將整個專案復原到先前的狀態、比對某一段時間的修改、查看最後是誰在哪個時間點做了錯誤的修改導致問題發生，誰在何時提出了某個功能缺陷⋯⋯等。 使用版本控制系統一般也意味著如果你做了一些傻事或者遺失檔案，你能很容易地恢復到原先的樣子， 但額外增加的工作量卻微乎其微。

本地端版本控制

很多人作版本控制的方法是把檔案複製到另一個目錄（如果他們夠聰明的話，他們還會幫資料夾加上時間）。 這種做法很常見，因為這樣做很簡單，但是卻也非常容易產生離譜的錯誤。 這種做法非常容易搞混資料夾，意外寫錯檔案或複製覆蓋到不想要的檔案。

為了解決這個問題，程式設計師很久以前就開發了很多種本機版本控制系統，大多都是採用某種簡單的資料庫來紀錄檔案的所有變更記錄。

本機版本控制示意圖
圖表 1. 本機版本控制

其中最流行的一種叫做 RCS，至今許多電腦上都還可以找到他的蹤影。 甚至在流行的 Mac OS X 系統中，只要安裝了開發者工具包以後，你就會有 rcs 的指令可以使用。 RCS 的工作原理是在硬碟上保存一堆特殊格式的補丁集合（patch set，即檔案從一個版本變更到另一個版本所需資訊）；通過套用任意的補丁，便可以重新產生出每個版本的檔案內容。

集中化的版本控制系統

接下來人們又遇到了重大問題，就是如何和其他電腦上的開發者協同合作？ 為了解決這個問題，於是集中化的版本控制系統應運而生。 這類系統（如：CVS、Subversion 和 Perforce），都有一個伺服器來管理所有版本的檔案，而許多用戶端會連到這台伺服器取出檔案來使用。 多年以來，這儼然成為版本控制系統的標準做法。

集中化的版本控制系統示意圖
圖表 2. 集中化的版本控制系統。

相對於本機版本控制系統，這種做法帶來了許多好處。 舉例來說，每個人都可以一定程度的知道專案中的其他人正在做些什麼。 管理員也可以輕鬆掌控每個開發者的權限；而且比每個用戶端只用本機的版本控制系統好管理很多。

然而，集中化的版本控制系統也有一些嚴重的缺點。 最嚴重的當然是中央伺服器如果發生故障的時候。 如果當機一小時，那麼這個小時之中，沒有人可以提交更新，也就無法協同合作。 如果中心版本庫的硬碟發生損壞，又沒有做適當的備份，那麼你就絕對會遺失所有資料——包括專案的全部變更歷史，只會剩下用戶端各自機器上保留的單獨快照。 本機版本控制系統也存在類似的問題——只要你的專案歷史都放在同一個地方，就有遺失所有資料的風險。

分散式版本控制系統

於是分散式版本控制系統（Distributed Version Control Systems，簡稱 DVCSs）就此登上舞台。 在 DVCS 系統（如 Git、Mercurial、Bazaar 和 Darcs）中，用戶端並不只取出最新的檔案快照；還把整個倉儲做個鏡像。 假設有任何一個協同合作的伺服器故障，事後都可以用任何一個用戶端的鏡像來還原。 因為每個地方都有完整的資料備份。

分散式版本控制示意圖
圖表 3. 分散式版本控制

除此之外，許多這類的系統都可以很好的和許多遠端倉儲互動，所以你可以和不同群組的人使用不同的方式，在同一個專案內協同合作。 你可以根據需要設定許多工作流程（如：階層式模型），這是在集中式的版本控制系統中是無法實現的。

scroll-to-top