-
A1. 附錄 A: Git 在其他環境
- A1.1 圖形介面
- A1.2 Visual Studio 中的 Git
- A1.3 Visual Studio Code 中的 Git
- A1.4 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git
- A1.5 Sublime Text 中的 Git
- A1.6 Bash 中的 Git
- A1.7 Zsh 中的 Git
- A1.8 PowerShell 中的 Git
- A1.9 小結
-
A2. 附錄 B: 在應用程式中嵌入 Git
-
A3. 附錄 C: Git 命令
1.1 入門 - 關於版本控制
本章將介紹 Git 的入門知識。我們將首先解釋版本控制工具的一些背景知識，然後介紹如何在您的系統上執行 Git，最後是如何設定 Git 以開始工作。在本章結束時，您應該理解 Git 存在的原因、為什麼要使用它，並且您應該已經做好了開始使用的所有準備。
關於版本控制
什麼是“版本控制”，你為什麼要關心它？版本控制是一個系統，它記錄檔案或檔案集隨時間的變化，以便您以後可以召回特定版本。在本書的示例中，您將使用軟體原始碼作為受版本控制的檔案，但實際上，您可以使用計算機上的幾乎任何型別的檔案進行此操作。
如果你是一名平面設計師或網頁設計師，並且想保留影像或佈局的每個版本（這當然是你最希望的），那麼使用版本控制系統（VCS）是非常明智的選擇。它允許您將選定的檔案恢復到以前的狀態，將整個專案恢復到以前的狀態，比較隨時間的變化，檢視誰最後修改了可能導致問題的內容，誰在何時引入了問題等等。使用 VCS 通常也意味著如果你搞砸了或丟失了檔案，你可以輕鬆恢復。此外，所有這些都只需要很少的開銷。
本地版本控制系統
許多人選擇的版本控制方法是將檔案複製到另一個目錄（如果他們夠聰明，可能會是一個帶有時間戳的目錄）。這種方法非常普遍，因為它如此簡單，但也極易出錯。很容易忘記你所在的目錄，然後意外地寫入錯誤的檔案或覆蓋你不想覆蓋的檔案。
為了解決這個問題，程式設計師們很早以前就開發了本地 VCS，它們有一個簡單的資料庫，用於儲存受版本控制檔案的所有更改。
最流行的 VCS 工具之一是名為 RCS 的系統，它至今仍隨許多計算機分發。RCS 的工作原理是將補丁集（即檔案之間的差異）以特殊格式儲存在磁碟上；然後它可以透過累加所有補丁來重建任何檔案在任何時間點的樣子。
集中式版本控制系統
人們遇到的下一個主要問題是他們需要與在其他系統上的開發人員協作。為了解決這個問題，集中式版本控制系統（CVCS）應運而生。這些系統（如 CVS、Subversion 和 Perforce）都有一個包含所有版本化檔案的中央伺服器，以及許多從該中央位置檢出檔案的客戶端。多年來，這一直是版本控制的標準。
這種設定提供了許多優勢，特別是相對於本地 VCS 而言。例如，專案中的每個人都在一定程度上知道其他人在做什麼。管理員可以對誰能做什麼進行細粒度控制，並且管理 CVCS 遠比處理每個客戶端上的本地資料庫容易。
然而，這種設定也有一些嚴重的缺點。最明顯的是集中式伺服器代表的單點故障。如果該伺服器宕機一小時，那麼在這期間，沒有人能夠進行協作或儲存他們正在進行的任何版本化更改。如果中央資料庫所在的硬碟損壞，並且沒有妥善的備份，您將失去一切——除了人們本地機器上可能有的單個快照之外，專案的整個歷史都將丟失。本地 VCS 也存在同樣的問題——只要您將專案的整個歷史儲存在一個地方，您就面臨失去一切的風險。
分散式版本控制系統
這就是分散式版本控制系統（DVCS）發揮作用的地方。在 DVCS（如 Git、Mercurial 或 Darcs）中，客戶端不僅檢出檔案的最新快照；相反，它們會完整地映象整個倉庫，包括其完整的歷史記錄。因此，如果任何伺服器發生故障，並且這些系統是透過該伺服器進行協作的，那麼任何客戶端倉庫都可以被複制回伺服器以進行恢復。每個克隆都是所有資料的完整備份。
此外，許多此類系統能夠很好地處理多個遠端倉庫，因此您可以在同一個專案中同時以不同方式與不同人群協作。這使您能夠設定幾種在集中式系統中不可能實現的工作流程型別，例如分層模型。
