-
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 的存在原因、您應該使用它的原因，並且您應該已做好使用的準備。
關於版本控制
什麼是「版本控制」，您為什麼應該關心它？版本控制是一個系統，用於記錄一段時間內對檔案或一組檔案的變更，以便您稍後可以回顧特定版本。在本書的範例中，您將使用軟體原始碼作為要進行版本控制的檔案，但實際上，您幾乎可以使用電腦上的任何類型檔案來執行此操作。
如果您是平面設計師或網頁設計師，並且想要保留圖像或版面的每個版本（您當然會想要這樣做），那麼使用版本控制系統 (VCS) 是一個非常明智的做法。它允許您將選定的檔案還原到先前的狀態、將整個專案還原到先前的狀態、比較一段時間內的變更、查看上次修改可能導致問題的內容的人員、引入問題的人員和時間等等。使用 VCS 通常也意味著，如果您搞砸了事情或遺失檔案，您可以輕鬆恢復。此外，您只需很少的額外負擔即可獲得這一切。
本機版本控制系統
許多人選擇的版本控制方法是將檔案複製到另一個目錄（如果他們聰明，可能會複製到具有時間戳記的目錄）。這種方法非常常見，因為它非常簡單，但也非常容易出錯。很容易忘記您所在的目錄，並且不小心寫入錯誤的檔案或複製覆蓋您不想覆蓋的檔案。
為了處理這個問題，程式設計師很久以前就開發了本機 VCS，這些 VCS 具有一個簡單的資料庫，可以保留所有在修訂控制下的檔案的變更。
最流行的 VCS 工具之一是一個名為 RCS 的系統，它至今仍與許多電腦一起發行。 RCS 的工作方式是在磁碟上以特殊格式保留修補程式集（即檔案之間的差異）；然後，它可以透過加總所有修補程式來重新建立任何檔案在任何時間點的樣子。
集中式版本控制系統
人們遇到的下一個主要問題是，他們需要與其他系統的開發人員協作。為了解決這個問題，開發了集中式版本控制系統 (CVCS)。這些系統（例如 CVS、Subversion 和 Perforce）具有一個包含所有版本化檔案的單一伺服器，以及許多從該中心位置檢出檔案的用戶端。多年來，這一直是版本控制的標準。
這種設置提供了許多優點，特別是相較於本地 VCS 而言。例如，每個人在某種程度上都知道專案中其他人在做什麼。管理員可以對誰能做什麼進行細粒度的控制，並且管理 CVCS 比處理每個用戶端上的本地資料庫要容易得多。
然而，這種設置也有一些嚴重的缺點。最明顯的是集中式伺服器所代表的單點故障。如果該伺服器停機一小時，那麼在這段時間內，沒有人可以協作，也無法將版本化的變更儲存到他們正在處理的任何內容。如果中央資料庫所在的硬碟損壞，並且沒有保留適當的備份，您將會遺失所有資料 — 整個專案的歷史記錄，除了人們恰好在本地機器上擁有的任何單一快照之外。本地 VCS 也會遇到相同的問題 — 當您將整個專案的歷史記錄儲存在單一位置時，您就有遺失所有資料的風險。
分散式版本控制系統
這就是分散式版本控制系統 (DVCS) 的用武之地。在 DVCS（例如 Git、Mercurial 或 Darcs）中，用戶端不只是檢出檔案的最新快照；相反地，他們會完整鏡像儲存庫，包括其完整歷史記錄。因此，如果任何伺服器當機，並且這些系統透過該伺服器進行協作，則可以將任何用戶端儲存庫複製回伺服器以進行還原。每個複製都是所有資料的完整備份。
此外，許多這些系統可以很好地處理多個可以協作的遠端儲存庫，因此您可以在同一個專案中同時以不同的方式與不同的群體協作。這讓您可以設置集中式系統中無法實現的幾種工作流程，例如階層式模型。
