很多人認爲 Git 難以理解的第一個門檻在於：所謂的「Git 是一個分佈式版本控制系統」這句話的具體含義不夠清楚。其實分佈式版本控制系統（Distributed Version Control System - DVCS）這個定義並不難，不過一步一步來，我先告訴你，什麼是版本控制系統（Version Control System - VCS）。
版本控制：最基本功能
版本控制系統（VCS）最基本的功能是版本控制。所謂版本控制，意思就是在文件的修改歷程中保留修改歷史，讓你可以方便地撤銷之前對文件的修改操作。
最簡化的版本控制模型，是大多數主流文本編輯器都有的「撤銷（Undo）」功能：你本來想刪除一個字符，卻在按刪除鍵之前不小心選中了全文，結果一下子整篇文檔都被刪光了，沒關係，按一下「撤銷」(Ctrl + Z 或 ⌘ + Z 或 U 等等，具體和你的操作系統以及編輯器有關），刪掉的文字就都回來了。這其實是文本編輯器幫你自動保存了之前的內容，當你按下「撤銷」的時候，它就幫你把內容回退到上一個狀態；同理，按一次是會退到上一個版本，按兩次就是回退到上上一個版本。
寫程序的時候同樣也難免會遇到「寫錯」的情況，所以程序的 VCS，當然也會需要版本控制功能，這樣當你發現「昨天有一行代碼寫錯了」，你就不用憑着記憶把那段代碼背出來，而只需要在 VCS 中選擇撤回到昨天的那個版本。
主動提交：程序代碼和普通文本的區別
VCS 和文本編輯器的撤銷功能比起來，有一個很重要的區別是：程序代碼的修改的生命週期非常長。一次代碼的修改，在幾天後、幾個月後、幾年後都有可能需要被翻出來。如果依然採用「每次改動自動保存」的形式來保留修改歷史，將會導致改動歷史非常頻繁和無章可循，這樣，歷史代碼的查找、閱讀和回退就會很困難了。所以，和文本編輯器的撤銷功能不同，VCS 保存修改歷史，使用的是主動提交改動的機制。
在你寫了一段完整的代碼（例如修復了一個 bug）之後，使用 commit 命令把改動和對改動的描述信息提交，這次改動就被記錄到版本歷史中了。之後如果你希望回退到這個版本，就可以從 VCS 的歷史日誌中方便地找到它。
多人合作的同步需求：中央倉庫
代碼可以一個人寫，但更多的時候會是多個人共同開發。那麼自然地，就需要有一箇中央倉庫作爲代碼的存儲中心：所有人的改動都會上傳到這裏，所有人都能也都能看到和下載到別人上傳的改動。
這樣，解決了同步的需求，多個人在不同的機器上開發同一個程序就成了可能。
版本控制、主動提交、中央倉庫這三個要素，共同構成了版本控制系統（VCS）的核心：開發團隊中的每個人向中央倉庫主動提交自己的改動和同步別人的改動，並在需要的時候查看和操作歷史版本，這就是版本控制系統。
中央式版本控制系統
最初的版本控制系統，是中央式版本控制系統（Centralized VCS），也就是前面我講的這種。Git 是分佈式的版本控制系統（Distributed VCS），它和中央式的區別我在下節說，現在先說一下中央式版本控制系統的工作模型。
工作模型
假設你在一個三人團隊，你們計劃開發一個軟件或者系統，並決定使用中央式 VCS 來管理代碼。於是：
- 作爲項目的主工程師，你獨自一人花兩天時間搭建了項目的框架；
- 然後，你在公司的服務器（這個服務器可以是公司內的設備，也可以是你們買的雲服務）上創建了一箇中央倉庫，並把你的代碼提交到了中央倉庫上；
- 你的兩個隊友從中央倉庫取到了你的初始代碼，從此刻開始，你們三人開始並行開發；
- 在之後的開發過程中，你們三人爲了工作方便，總是每人獨立負責開發一個功能，在這個功能開發完成後，這個人就把他的這些新代碼提交到中央倉庫；
- 每次當有人把代碼提交到中央倉庫的時候，另外兩個人就可以選擇把這些代碼同步到自己的機器上，保持自己的本地代碼總是最新的。
而對於團隊中的每個人來說，就會更簡單一點：
- 第一次加入團隊時，把中央倉庫的代碼取下來；
- 寫完的新功能提交到中央倉庫；
- 同事提交到中央倉庫的新代碼，及時同步下來。
這樣，一個三人的團隊就成功做到了各自在自己的電腦上開發同一個項目，並且互不影響，就好像你們三個人是在同一臺電腦上操作一樣。
這就是中央式 VCS 最基本的工作模型。當然，實際的開發工作並沒有簡單到這種程度，因爲你時常會需要處理代碼衝突、查看版本歷史、回退代碼版本等；另外，Git 屬於分佈式 VCS，它的概念也比中央式 VCS 要複雜一些。