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