版本控制入门：U盘类比

Source: Dev.to

版本控制之前的生活

想象一下：你是 1990 年代的开发者，正在构建软件。遇到了一个无法修复的 bug，你想让同事 John 帮忙。你已经拥有源代码。你该如何把代码传给他？

U 盘问题

也许通过使用 U 盘、硬盘、电子邮件或光盘，你把代码复制并交给约翰。约翰把代码复制到他的系统中并开始工作。修复了错误后，约翰删除了你原来的代码，将更新后的版本复制到 U 盘，并把它还给你。你从 U 盘上复制代码，发现原来的错误已经修复，但代码的意外位置出现了另一个错误。

为什么 final_final_v2 从未真正“最终”

此时你已经感到困惑。是新的 bug 你的错还是 John 的错？没有办法确认。

两位开发者决定，每次修改代码时，都不从 U 盘中删除旧的代码，而是把新代码保存为 final。

随着代码库的增长，出现了许多令人困惑的名称：final_v2、latest_final、latest_final_final、latest_final_super_final 等等。

为什么团队需要更好的系统

现在你又感到困惑。最新的代码是哪一个？谁改动了哪一部分？为什么会出现意想不到的 bug？

这些问题已经让两位开发者感到痛苦；想象一下再加入第三位开发者 Will，混乱会成倍增加。

你感到沮丧，因为无法追踪代码的更改。于是你决定构建一个记录每一次添加或重写以及每次更改作者的软件。这解决了多文件和多文件夹的问题：无论有多少开发者参与，大家都可以在同一个文件夹中工作。

这款软件就是 Git，由 Linus Torvalds 创建。

Source: …

什么是版本控制？

版本控制是一种系统，用于随时间跟踪文件的更改，显示哪些内容被更改、谁进行的更改以及何时进行的更改。

使用版本控制，你可以：

• 跟踪代码中的每一次更改
• 消除令人困惑的 final_final_v2 文件夹
• 防止意外覆盖
• 提供完整的更改历史
• 实现协作
• 精确展示具体更改内容
• 确认每次更改的作者

U 盘的局限性

即使使用了版本控制，你仍可能在使用 U 盘。U 盘始终只保存最新的代码，而且一次只能有一名开发者工作。其他人只能使用过时的副本，无法进行更改。

集中式仓库

为了解决这个问题，可以搭建一个托管 Git 仓库的中央服务器。该服务器始终保存代码的最新版本。所有开发者从服务器 pull 代码，完成修改后再 push 回去。

通过这种方式，所有开发者可以同时工作，并将他们的代码与唯一的真相来源——服务器上的代码进行比较。该服务器通常由 GitHub 提供。