如今，我们在创建Git仓库时缺乏用心和关怀。本文探讨了如何不使用常见的Git命令，而是通过手动方式创建Git仓库，以此深入了解Git的内部工作原理。作者强调，Git的强大之处并非源于其代码的复杂性，而是其设计的简洁与优雅。本文可以视为Git内部机制（即“管道”）的入门课程，甚至可以说是Git“流体力学”的初级教程。虽然这种方法看似有些愚蠢，但它能帮助读者更好地欣赏Git的设计之美。

文章主要内容总结

标题: 手工制作的Git仓库 | drew的开发博客
来源: https://drew.silcock.dev/blog/artisanal-git/

这篇文章探讨了如何手动创建Git仓库，而不使用常见的Git命令，从而深入了解Git的内部工作原理。作者通过逐步构建Git仓库的核心文件和目录，展示了Git的底层设计。

1. 背景与动机

作者指出，现代Git仓库的创建缺乏“手工制作”的精细感，因此他决定通过手动创建Git仓库来展示Git的内部机制。这不仅可以帮助读者更好地理解Git的工作原理，还能让大家欣赏Git设计的简洁与优雅。

2. 准备工作

作者假设读者已经熟悉Git的基本操作，并且能够在命令行环境中自如操作。文章主要面向有一定Git使用经验的开发者。

3. 手动创建Git仓库

作者从最基本的步骤开始，手动创建了一个Git仓库： - 创建.git目录及其子目录（如hooks、objects、refs等）。 - 配置.git/config文件，设置仓库的基本参数。 - 创建HEAD文件，指向默认分支main。

通过这些步骤，作者展示了如何在不使用git init命令的情况下，手动构建一个有效的Git仓库。

4. Git对象存储

Git使用内容寻址存储（Content Addressable Storage, CAS）来管理对象（如提交、文件等）。每个对象通过其内容的SHA-1哈希值进行标识。作者通过示例展示了如何查看和解析Git对象，包括提交对象（commit）、树对象（tree）和文件对象（blob）。

5. 提交对象与树对象

• 提交对象：包含提交的作者、时间戳、父提交哈希、树对象哈希等信息。
• 树对象：记录了文件的结构和权限信息，每个文件条目包含文件模式、文件名和文件内容的哈希值。

作者通过手动创建这些对象，展示了Git如何通过哈希值来管理和存储数据。

6. Git的差异计算

Git并不存储文件之间的差异（delta），而是存储文件的完整版本。当执行git diff时，Git会比较两个文件的完整内容，生成差异。这种方式虽然可能增加存储空间，但简化了版本控制的设计。

7. Git的打包机制

当Git仓库中的对象数量达到一定阈值时，Git会将多个对象打包成packfile，以提高存储效率。作者解释了Git如何通过索引文件来查找打包后的对象。

8. 手动创建第一个提交

作者通过手动创建文件对象、树对象和提交对象，最终生成了一个完整的提交，并将其与main分支关联。通过这种方式，作者展示了Git提交的底层实现。

9. 总结与未来话题

虽然手动创建Git仓库的过程很有趣，但作者并不建议在实际项目中使用这种方式，因为它容易出错。文章最后，作者提到了一些未来可能探讨的话题，如Git的存储机制、索引文件格式、网络通信等。

10. 进一步阅读

作者推荐了一些关于Git内部机制的进一步阅读材料，包括Julia Evans的博客文章和Git官方文档。

结论

通过手动创建Git仓库，作者展示了Git的底层设计，强调了其简洁和优雅。虽然这种方式并不适合实际项目，但它为开发者提供了一个深入了解Git内部机制的机会。

1. 关于Git的易用性和透明度

   • 正面观点：Git的数据结构易于理解，透明度高，甚至可以通过阅读其内部机制来编写兼容的Git工具。
     • 引用："Something that I really like in Git is how its data structures are easy to understand and how transparent it is."（“我非常喜欢Git的一点是它的数据结构易于理解，且透明度高。”）
     • 引用："The simplicity of Git is awesome. Great article!"（“Git的简洁性很棒。好文章！”）
   • 负面观点：Git的内部数据结构操作可能显得繁琐。
     • 引用："I would have called this: 'Futzing around with internal git data structures'."（“我会称之为‘摆弄Git内部数据结构’。”）

2. 关于Git的替代工具

   • Mercurial的支持者：有人认为现在更常用Mercurial。
     • 引用："Pretty cool but nowadays we use Mercurial."（“很酷，但我们现在用Mercurial。”）
   • 其他工具的建议：有人建议探索其他分布式版本控制系统（如Fossil）是否可以使用类似rsync的算法来处理大文件。
     • 引用："Is it possible to somehow make Git use the Content Defined Chunking algorithm from rsync?"（“是否有可能让Git使用rsync的内容定义分块算法？”）

3. 关于Git的历史和创始人

   • 对Linus Torvalds的讨论：有人好奇Git的创始人Linus Torvalds如何使用Git，并提到Git的命名背景。
     • 引用："This is all very well but how does Linus Thorvalds use git?"（“这很好，但Linus Torvalds如何使用Git？”）
     • 引用："git was called git because a Finnish bloke with English as a second, but well used, tongue had learned what a 'git' is and it seemed appropriate."（“Git之所以叫Git，是因为一个芬兰人学会了‘git’这个词，觉得它很合适。”）

4. 关于Git的学习资源

   • 推荐学习资源：有人推荐通过动手实践来理解Git的内部机制，并推荐了相关学习资源。
     • 引用："Neat to see this done by hand! It helps demystify the magic behind git commands."（“很高兴看到手工操作！这有助于揭开Git命令背后的神秘面纱。”）
     • 引用："If you like this, I also recommend 'Write Yourself a Git'."（“如果你喜欢这个，我还推荐《Write Yourself a Git》。”）

5. 关于网站布局的反馈

   • 对网站布局的批评：有用户抱怨在MacBook Pro M1上阅读文本困难，建议改进布局以适应高分辨率显示。
     • 引用："I'm on a MBP M1 Mac and honestly I can't really read the text. Far too small."（“我在MacBook Pro M1上，说实话我几乎看不清文字。太小了。”）
     • 引用："Please, consider making the layout better for us old coders whose eyes are going, or for hi res displays."（“请考虑为视力下降的老程序员或高分辨率显示器改进布局。”）

6. 关于其他技术的类比

   • 对Docker的类比：有人希望看到类似文章探讨Docker如何使用OverlayFS存储镜像。
     • 引用："I would love to see a writeup on how Docker stores images using OverlayFS."（“我很想看到一篇关于Docker如何使用OverlayFS存储镜像的文章。”）

7. 关于文章主题的误解

   • 对文章主题的误解：有人误以为文章是关于在没有LLM的情况下编程的讽刺性文章。
     • 引用："I thought this was going to be a sardonic article about doing programming without LLMs."（“我以为这会是一篇关于在没有LLM的情况下编程的讽刺性文章。”）