Git 版本控制

内容寻址的存储模型

Git 的底层存储不是按文件路径索引，而是以内容的 SHA-1 哈希值为 key 的键值对象库。一个 commit 对象包含树（目录结构）、父 commit、作者信息和提交消息；树对象指向子树和 blob（文件内容）；blob 就是文件内容本身。这种内容寻址设计意味着：相同内容的文件只存储一次，且任何内容改动都会产生完全不同的哈希，数据完整性天然保证。

Git 的「分支」实质上只是一个指向 commit 对象的可移动指针，新建分支的成本几乎为零，这与 SVN 等中心化系统拷贝整个目录树的方式截然不同。[1]

工作流与协作模式

GitHub Flow 是最简单的工作流：从 main 拉出功能分支，提交 Pull Request，代码审查合并。Git Flow（Vincent Driessen，2010）更适合有明确发布周期的产品，维护 main、develop、feature、release、hotfix 五类分支。大型开源项目（如 Linux）则采用 维护者-贡献者模式，Torvalds 本人审查所有顶级合并。

几个常被误解的概念：git rebase 将提交「重新播放」到目标分支上，历史更线性但改写了历史（不适合已推送的公共分支）；git merge --no-ff 保留合并节点便于追溯；git bisect 用二分法快速定位引入 Bug 的具体提交。