问题一： 用 500 字说说 Git 的前生今世。
看到这个问题，脑中有疑问：
学习Git为什么要了解Git的前生今世?
了解前生今世有什么作用？
在了解Git的前生今世之后，有三个答案：
- 了解后能知道，Git能解决哪些需求和问题。每个阶段由什么问题推动Git的萌芽和发展。
- 可了解Git 的主要功能，特点，能更好的理解和实际使用。
- 用户需求，存在问题，催生产品，推动产品更新换代。
Git的前生今世 个人理解可划分为三个时段：
- 远古的石器时代 -- 无版本控制系统，协作困难
- 开化的近代 --集中式版本控制系统 主要有CVS和SVN
- 成熟的现代 --分布式版本控制系统 主要有BitKeeper和Git
一、远古的石器时代
- 在石器时代，人们一般用相对原始，简陋的工具来解决问题，完成工作内容。
- 这个时代在1985年CVS出现之前。 人们在修改文档和程序代码时，通过不断的复制，冗余存储，多人协作困难，效率低下。对于文本和源码的差异比较用diff 和patch来解决，代表人物是大名鼎鼎的Linus Torvalds（Linux之父）
二、开化的近代
- 这个时代在1985年，CVS（Concurrent Versions System）由荷兰阿姆斯特丹VU大学的Dick Grune教授实现，引入版本控制概念解决修改文档的复制存储，多人协作困难的问题。
- 但由于CVS存在问题：建立里程碑或分支时缺乏效率，服务器端文件越多，速度越慢。因为缺乏对合并的追踪从而导致重复合并，引发严重冲突，等等原因。
- 在2000年出现SVN（Subversion）——集中式版本控制系统，逐步取代CVS。
- SVN 有多个优点： 从BDB（简单的关系型数据库）到FSFS（文件数据库）的转变。FSFS相对于BDB具有更高的稳定性、免维护性，以及实现的可视性。利用轻量级拷贝，SVN在不同的名字空间下创建不同的目录实现里程碑和分支的创建，轻松地解决了CVS中存在的里程碑、分支创建速度慢又不可见的问题。使用SVN创建里程碑和分支只在眨眼之间。
- SVN 也存在的多个问题，例如：集中式版本控制系统，即一个项目只有唯一的一个版本库与之对应，所有的项目成员都通过网络向该服务器进行提交。单点故障是集中式版本控制的死穴，并由此带来数据备份和数据恢复的管理成本。此外集中式版本控制系统还存在着提交瓶颈。
三、成熟的现代
- 这个时代，分布式版本控制系统相对集中式，可以不需要集中式的版本库，每个人都拥有一个完整的版本库。分布式版本控制系统的几乎所有操作包括查看提交日志、提交、创建里程碑和分支、合并分支、回退等都直接在本地完成而不需要网络连接。每个人都是本地版本库的主人，不再有谁能提交谁不能提交的限制，加之多样的协同工作模型（版本库间推送、拉回，及补丁文件传送等）让开源项目的参与度有爆发式增长。
- 2005年Git诞生，由Linus开发一个分布式版本控制工具以替代BitKeeper，随着Git的开发者和使用者的增加，Git的使用界面也变得更友好。例如到1.5.4版本时，将一百多个独立的命令封装为一个git命令，使用习惯已经和其他版本控制工具非常一致了。10个人共孙子兵法
- Git取代SVN成为当之无愧的版本控制之王。在GitHub上的上百万个项目，很多耳熟能详：Linux kernel、Perl、Eclipse、Gnome、KDE、Qt、Ruby on Rails、Android、PostgreSQL、Debian、X.org。
问题二： 举例说明集中式与分布式版本控制的区别是什么？
- 多人异地共同读一本书 ，批注修改要所有人共享。
- 集中式半版本控制相当于古人，先要去把这本书从图书馆借到家中，再将修改的整本书送回去。书取送困难，狐本易出问题。
- 分布式版本控制，相当于现代，书可以复制多份，存在每个人手上，修改和批注也可以单独共享，不必将整本书传递。 书的复制与修改也不需依赖图书馆一个核心。
问题三：如何运用分支管理实现多人协作？
- 建造一艘大型航母，采用分段分部建设，最后集中到船厂组合建设。 每个分段在不同地方由不同厂家完成，多人协作，比只在一个船厂建设更快，更灵活。
