为什么 GIT 存在：U盘问题

Source: Dev.to

U盘问题

想象一个没有 Git 的世界：

1. 你需要一个新功能，于是请朋友 Rishi 帮忙。
2. 你把整个项目压缩，拷贝到 U 盘上，交给他。
3. Rishi 开发完功能后，把更新后的代码压缩后再交回 U 盘。

当你解压项目时会遇到多个问题：

• 看不出作者 —— 你无法判断哪些代码是谁写的。
• 改动不明确 —— 之后出现了 bug，却不知道到底改了什么、改在哪儿。
• 审查耗时 —— 你必须和 Rishi 坐下来逐行对比文件。
• 冲突与浪费 —— 修复时可能不小心修改或删除了重要代码，迫使你重新调试整个项目。

如果有多个开发者需要在同一代码库上工作，情况会更糟：

• 每一次改动都需要把整个项目压缩后再搬运 U 盘。
• 同一时间只能有一个人工作——持有 U 盘的人。
• 几乎不可能追踪哪些文件被谁修改过。

开发者的需求

追踪改动

一个系统能够：

• 记录对代码所做的每一次改动。
• 保存每次改动的作者信息。
• 显示旧版本与新版本之间的差异（diff）。
• 保留完整的版本历史。

支持协作

• 一个所有开发者都可以同时访问的唯一真相源（single source of truth）。
• 能够 pull 最新代码，独立工作后再 push 改动。
• 立即看到他人的贡献，无需手动交换文件。

Git 的诞生

Linus Torvalds 为管理快速增长的 Linux 内核而创建了 Git。随着项目规模扩大，传统的改动追踪方式已无法继续使用。Git 引入了 分布式版本控制系统（DVCS），同时解决了追踪和协作的问题。

• 分布式 —— 每个开发者都有完整的仓库副本，消除了单点故障。
• 高速 —— 提交、分支、合并等操作都在本地完成。
• 可靠 —— 加密哈希确保数据完整性。

GitHub（以及类似的托管服务）提供了一个中心服务器，用来存放仓库，方便开发者共享与协作。

GitHub 的替代方案

虽然 GitHub 是最流行的托管 Git 服务，但还有其他选择：

• Bitbucket
• GitLab
• Gitea
• Codeberg

其他版本控制系统

在 Git 成为主流之前，人们使用过以下 VCS 工具：

• AWS CodeCommit
• Apache Subversion (SVN)
• Unity Version Control
• Fossil
• Concurrent Versions System (CVS)

结论与展望

Git 的出现是为了解决“U 盘问题”以及更广泛的改动追踪与协作难题。了解这段历史有助于我们更好地体会 Git 在现代软件开发中的强大力量。

在下一篇文章中，我们将深入探讨 Git 的内部工作原理，了解其核心概念，并检查 .git 目录的文件结构，看看背后到底发生了什么。