版本控制
1.项目协同开发
介绍
我们进行项目开发时，由于项目的庞大，通常都是由多人协同进行开发，每个人负责部分业务代码的开发，一起推进项目的进度。但多人协同开发不可避免地会存在很多的问题，例如代码共享、代码合并、历史回退、权限控制、日志记录等问题
问题
- 代码共享：建立一个专门的服务器管理代码
- 代码合并：复制粘贴，肉眼观察，极易出错
- 历史回退：在修改代码之前，做好每次修改前的备份（复制粘贴）
- 权限控制：人为控制，非常麻烦
- 日志记录：人为控制，非常麻烦
为了解决上述问题，我们急需一款软件能够帮助进行项目的协同开发
2.什么是版本控制系统
版本控制系统（Version Control System, VCS）是用于管理和追踪文件修改历史的软件工具，它记录和跟踪从创建到当前状态的所有源代码及项目文件变化，支持团队协作、版本回溯、差异对比以及合并不同成员的工作
我们可以把一个版本控制系统理解为一个“数据库”，它可以帮助我们完整地保存一个项目的快照。当我们需要查看一个之前的快照（称之为“版本”）时，版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。下图为版本控制系统的工作流程
3.版本控制的好处
试想一下，如果没有版本控制系统，当需要处理那些共享文件夹中的文件时，我们必须告知团队里的所有人，正在对哪些文件进行编辑。与此同时，其他人必须避免操作相同的文件。这是一个不现实和完全错误的流程。当我们花了很长时间完成编辑后，可能这些文件早已经被团队里的其他开发成员修改或者删除了
如果使用了版本控制系统，团队中的每个成员都可以在任何时间对任何文件毫无顾虑地进行修改，版本控制系统可以把之后所有的改动合并成一个共同的版本，不论是一个文件还是整个项目。这个共同的中心平台就是我们的版本控制系统
4.版本控制系统的分类
- 集中化版本控制系统：典型产品SVN
- 分布式版本控制系统：典型产品GIT
5.集中化版本控制系统
介绍
集中化版本控制系统诸如：CVS，SVN，Perforce等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器上，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法
优点
- 使用简单：由于整体工作流程很简单，所以学习和使用它都比较简单
- 已于权限管理：管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统；要远比在各个客户端上维护本地数据库来得轻松容易
缺点
- 单点故障：如果中央服务器出现故障，那么整个代码版本将会丢失，除非之前有备份。然而，由于版本库持续不断地更新，即使有备份，也会丢失最近的版本，除非备份频率设置得非常高
- 无法工作：如果没有网络，也就无法进行协同开发，项目进展将会因而受阻
6.分布式版本控制系统
介绍
每个人的计算机都是一个完整的版本库，开发人员开发完某个功能后直接将代码提交到自己本地的仓库中即可。这样，即使没有联网，也可以进行项目开发，就不存在集中式的单点故障问题了
注意
Git记录版本历史只关心文件数据的整体是否发生变化。Git不保存文件内容前后变化的差异数据
优点
- 离线工作：可以先存入本地仓库，无需像SVN一样如果需要产生一次快照，则必须提交到远程仓库
- 适合分布式开发，强调个体
- 公共服务器压力和数据量都不会太大
- 速度快，灵活
- 任意两个开发者之间可以很容易的解决冲突
缺点
- 学习周期较长：入门简单，但是整体学习下来时间较久
- 易学难精：学习起来还算容易，但是整体工作机制还是比较复杂的，要精通比较困难
7.GIT与SVN核心对比
GIT
Git在本地会有一整套版本控制服务，在这个版本控制服务中可以进行代码的提交、生成版本快照信息等；使用Git的项目团队的每一个成员开发项目时，如果需要产生一次版本，可以提交到本地仓库，等到需要将功能发布给团队的其他人时再发布到远程仓库，其他人通过拉取远程仓库的代码来更新自身的本地仓库
SVN
在SVN中，每次功能开发完毕，如果需要产生一次快照，则必须提交到远程仓库（中央仓库），这一过程无疑要求开发者具备网络连接。因此，若使用SVN的开发团队离开了中央仓库，则团队的每个成员都将无法提交数据产生版本信息了；除非使用SVN的项目团队成员开发完某个功能后可以先提交到本地仓库，产生一次快照信息。但遗憾的是，SVN并不支持此类操作。另外，如果SVN能够支持这样类似的操作，那么，它便会归类为分布式版本控制系统，而不再是集中式版本控制系统了
