本篇文章更新時間：2026/01/28
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
我從零打造一個迷你版 Git：讀《I made my own git》有感
編輯前言：這篇文章來自 Tony Johansson 的《I made my own git》，作者嘗試用 Rust 重寫一個簡化版的 Git。我讀完後的感覺是：它不只是工程實作筆記，更像是一堂把 Git 拆開、摸透、再組回去的深度課程。
核心觀點 (Key Takeaways)
- Git 的本質其實是「以內容為基礎的 key-value store」。物件以 hash（原文作者選 SHA-256）命名並存進 objects 目錄。
- 版本控制最核心的三件事：hash、tree、commit —— 其他都是細節。
- 自己實作一遍後，作者發現「真正難的不是演算法，而是物件格式 parsing」。如果重來一次，他會改存成 JSON 或 YAML。
深入解析
Tony 一開始提到，他過去把 Git 當成黑盒子用：不知道檔案怎麼被儲存、差異怎麼生成、commit 是怎麼組成的。於是他乾脆自己做一套，順便以 Rust 為練習場。
「It really drove home the idea that git is just a content-addressable file store.」
這句話幾乎是全文的中心思想——當我們把 Git 的外殼剝掉後，它就只是個可以用內容當 key 來找到檔案的資料庫。
1. Hash 與物件儲存的運作原理
Git 會為每個檔案、tree、commit 計算 hash，並將內容壓縮後放到 .git/objects/。Tony 雖然知道 Git 用 SHA‑1，但因為沒有相容性需求，直接換成 SHA‑256。
壓縮部分也類似：Git 用 zlib，他改成採用 zstd，理由很簡單：效能比較好，他也不追求相容。
這裡我覺得很有意思——許多「知識性工具」之所以難，是因為我們背負了相容性跟歷史包袱；一旦丟掉這些顧慮，你會發現核心概念其實意外地簡單。
2. 實作 commit 的基本結構
全文最具參考價值的，是作者自己定義的 commit 格式：
\0
tree
parent
author
message
就算少了 Git 的 author/committer 區分、object size 等資料，其實也已經足夠完成最基本的版本控制。Tony 寫得很坦白：大部分 commit 的 author 和 committer 都一樣，他根本不需要那些功能。
3. Checkout 的困難點：解析物件字串
這是作者形容最麻煩的部分。由於他自己定義的格式不算嚴謹，後續 parse commit 或 tree 字串就變得冗長而易錯。
於是他最後的反思是：
「If I were to do this again, I would probably use a well-defined language like yaml or json to store object information.」
這也讓我想到很多軟體架構的最佳實踐——早知道就直接用現成格式，省下無數 parsing 的坑。
筆者心得與啟發
讀完我最大的收穫，是重新理解 Git 的本質：它不是複雜的魔法，而是由幾個非常簡單的抽象組起來的系統。
Tony 的自製版 Git（tvc）其實傳達了一個重要訊息：
版本控制工具的強大，往往來自它的資料結構，而不是複雜的功能堆疊。
以前我用 Git 的時候常常覺得 commit、HEAD、tree、object 很抽象；但看完這篇文章後，我反而覺得它們簡單得不可思議。特別是當 Tony 示範 commit 生成、tree 遍歷、hash 存取的流程後，我突然理解了 Git 為什麼能做到「相同內容就只存一次」、「快速切換版本」、「指向 commit 就能還原整個檔案系統」。
如果你也想真正搞懂 Git，而不是只會背幾個指令，我會推薦你自己做一個迷你版本。不用完整、不用相容，照著 Tony 的思路拆一遍，你會對 Git 的理解瞬間提升一個層級。
原文連結：I made my own git