开发中的实际场景
场景一：备份
小明负责的模块就要完成了，就在即将 Release 之前的一瞬间，电脑突然蓝屏，硬盘光荣牺牲！几个月来的努力付之东流
场景二：代码还原
这个项目中需要一个很复杂的功能，老王摸索了一个星期终于有眉目了，可是这被改得面目全非的代码已经回不到从前了。什么地方能买到哆啦 A 梦的时光机啊？
场景三：协同开发
小刚和小强先后从文件服务器上下载了同一个文件：Analysis.java。小刚在 Analysis.java 文件中的第 30 行声明了一个方法，叫 count ()，先保存到了文件服务器上；小强在 Analysis.java 文件中的第 50 行声明了一个方法，叫 sum ()，也随后保存到了文件服务器上，于是，count () 方法就只存在于小刚的记忆中了
场景四：追溯问题代码的编写人和编写时间！
老王是另一位项目经理，每次因为项目进度挨骂之后，他都不知道该扣哪个程序员的工资！就拿这次来说吧，有个 Bug 调试了 30 多个小时才知道是因为相关属性没有在应用初始化时赋值！可是二胖、王东、刘流和正经牛都不承认是自己干的！
版本控制器的方式
文本提取
a、集中式版本控制工具
集中式版本控制工具，版本库是集中存放在中央服务器的，team里每个人work时从中央服务器下载代码，是必须联网才能工作，局域网或互联网。个人修改后然后提交到中央版本库。
举例：SVN和CVS
b、分布式版本控制工具
分布式版本控制系统没有"中央服务器"，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需要联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了。
举例：Git
2.3、SVN
（配图为集中式架构示意图：一台中央服务器连接多台客户端设备）
核心知识点解读💡
-
集中式（SVN/CVS）
- 核心：唯一中央服务器存储所有代码版本，本地只有当前工作文件
- 缺点：断网无法工作；服务器故障则全部数据丢失；多人提交易覆盖代码
- 优点：权限管理简单，适合小型团队
-
分布式（Git）
- 核心：每台电脑都是完整仓库，本地可离线管理版本，云端仅用于协作同步
- 优点：离线可用、数据安全、分支灵活、适合开源/大型团队
- 缺点：学习成本略高
两者核心区别
| 特性 | 集中式(SVN) | 分布式(Git) |
|---|---|---|
| 版本库位置 | 仅中央服务器 | 本地+远程都有完整库 |
| 网络依赖 | 必须联网 | 本地可离线，推送/拉取才需联网 |
| 安全性 | 服务器损坏则数据丢失 | 多副本，容错性强 |
| 代表工具 | SVN、CVS | Git |
SVN
git
Git 是分布式的，Git 不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用 Git 并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的 PC 是一样的。我们可以把它当做一个开发者的 pc 就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过 "交换" 修改不方便而已。
git 是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991--2002 年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。他们对新的系统制订了若干目标：
速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
