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