# Outline
一、前言
二、論述

# TL;DR
...

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、前言

今天在整理整個系列的綱要時，覺得可以在比較前面的部分提及分散式版控和集中式版控比較的部分。所以打算用剩餘不多的時間，先簡單論述這部分，並留下一些問題，在這三天尋找出答案。預期這邊會放在講完歷史，還沒講 Git 儲存的資料結構的部分。

這篇也會算是一個整個 Git 設計概念的導讀，先帶讀者順過一次整體概念，比較好把後面要分章講的概念串起來。而讀完整個系列後又可以回頭再看一次本篇文章，重新溫習整個比較系統的概念。

二、論述

Git 有一個很重要的特性，就是分散式的版本控制，所有人在自己電腦都會有一份完整的程式碼版本控制的資料庫，包括程式碼託管平台（GitLab、GitHub）也是如此。這個在現在看起來很普遍的特性，在早起卻不是如此，這其中的歷史可以參見[[How Git Born：以史為鏡，可以 Git 興替]]，這邊只簡單帶過。

早期諸如 SVN 知名的版本控制系統都是集中式版本控制，所以工程師的電腦裡只會有某個特定的版本，修改完後再合併回版本控制的伺服器。當某個人 Checkout 某些檔案時，那些檔案就會被鎖定（Lock）住，其他人就不能去修改他，直到那個人把 Checkout 出來的檔案 Checkin 回去。這種情境可想而知開發相比現在習慣的方式會感到很不方便。

而如前面所說，Git 每一個人都會有完整的版本，更重要的事 Git 不是透過儲存兩個版本之間的差異去做版本控制，而是儲存當前版本的狀態去做版本控制，就像照相一樣去紀錄，所以又被稱為快照。而每個被「照到」的檔案都會被存進 Git 的資料庫，只要不同內容就會被視為不同的檔案，存進去。

每一個快照就是一個 Commit，而每個 Commit 會指向一個儲存當前 Commit 目錄結構的資料，透過這個資料去瞭解這個版本用到了那些被照到的檔案，從而能還原出當時「照片」的景象。

每個 Commit 是不斷指向前一個 Commit，透過這樣的方式去建立起一條鏈。一個 Commit 可能會被多個 Commit 指向，所以就會有了分岔，每個分岔都會一個名稱指向該分岔的某個 Commit 或最新的 Commit，讓這個分岔有名字，讓我們觀測到所謂分支的圖像，但事實上就只是許多有共同祖先或歷史的 Commit 鏈將相同的部分重疊在一起罷了。

也因為這個機制，分支變得成本低，每個人都可以放心地建立起自己的版本。在同步彼此的 Git 資料庫時，只要同步到被儲存的檔案，以及每個人的分支是指向哪一個 Commit 即可。從而達到分散式的版本控制。