在今天的這篇，在知道為什麼我會選擇樂高作為 GIT 的比喻案例之前，我想先開始思考及討論，在原始碼的開發者耕耘生成過程中，對於原始碼的生滅有些什麼樣的變化？版本控制控制些什麼？GIT 版本控制跟這些變化的關聯是什麼？

先舉個例子：

我們先看以下這個 HTML 原始碼編輯的例子：

• 假設先有一個 HTML 的基本原始碼
• 我在內容中加入了第一行原始碼 <div>Apple 1</div>
• 接著加入第二行原始碼 <div>Apple 2</div>
• 然後新增第三行 <div>Apple 3</div> 並且修改第一行改為 <div>Apple 0</div>

原始碼的變化其實是怎麼樣：

• 有一個基礎的樣貌
• 根據與基礎樣貌的差異，發現目前增加了一行
• 根據上個步驟的結果，發現目前又新增了一行
• 根據上個步驟的結果，發現不僅多了一行還修改了一些原本的內容

原始碼的生滅有些什麼樣的變化呢？

我們可以想像，這些原始碼的變化，其實是一層一層的堆疊而來，每一層的堆疊，都是自上一層的結果累積，這些累積其實是記錄著根據上一層的堆疊之後的一些變化，這些變化可能是新增、刪除、修改一些原始碼。

版本控制控制些什麼？

還記得周星馳「武狀元蘇乞兒」電影裡降龍十八掌的最後一掌要怎麼打出來嗎？把前面的十七掌融合一起，就是十八掌了。版本控制之於降龍十八掌，第十八掌就是自前面的十七式的累積，因此每一式怎麼打都很重要，需要蘇乞兒手上的那本降龍十八掌秘笈，一式一式的紀錄著每一式怎麼實現的細節，最後融合在一起，才能成為第十八式。

版本控制在控制的，也就是這每一式(如上面的例子，也就是每一層)，只是對象變成原始碼，改為記錄著目前原始碼相對於之前多了什麼？少了什麼？這次的變化是為了什麼？變化的原因是什麼？誰做了這些變化？

GIT 版本控制跟這些變化的關聯是什麼？

有用過 GIT 的朋友，還記得在 CLI 下了指令 git clone 某個 repo 之後，會看到的畫面是什麼嗎？如果沒有以下這個畫面供您回憶。

如上面的動畫中，可以看到，從開始執行指令後的那些指令描述，有一連串從遠端接收物件 (receiving objects) 以及解析變化 (Resolving deltas) 的動作。如前面所提到的，在 GIT 這個原始碼的版本控制工具裡，物件們 (objects) 存放的就是原始碼一層一層的變化，解析變化，就是依序把這些變化依照解析的結果一層一層堆疊回來。

樂高

我要怎麼組裝出跟這架直升機一樣的直升機呢？

• 首先，需要有一本可以跟隨操作的手冊

  

• 接著會有一個基底，通常是第一片

• 然後跟著手冊一層一層的堆疊

• 完成所有步驟後，可以得到同樣的直昇機

樂高、樂高手冊與 GIT 的關聯

因此，樂高、樂高手冊，之於 GIT 版本控制，每一塊樂高積木，可以想像是 GIT 裡的物件們，樂高手冊，就像紀錄這些物件變化的地方，玩家們只需要根據手冊的步驟，一步接著一步，就可以做出和手冊一樣的直升機。

總結：

原始碼的版本控制，現在的原始碼是累積自過去每一次一次的變化，版本控制在控制的，也就是在紀錄改變，紀錄那一層一層的累積變化，只要你能解讀這些紀錄，並照著記錄的編寫原始碼，便也能如紀錄一樣，最後形成和記錄者一樣擁有同樣的原始碼；就像樂高積木一樣，透過說明手冊，紀錄著每個步驟有什麼樣的改變，只要跟著手冊的紀錄，一層一層、一塊一塊的堆疊，也能同樣累積出形成同樣的形狀。