这是我参与「第三届青训营 -后端场」笔记创作活动的第二篇笔记。

写在前面：笔者在物联网公司实习时，因为代码开发量低，且几乎没有同时进行协作开发，所以部门内部使用的是SVN集中式版本管理系统。而在做青训营大项目时，使用了当下最为流行的Git分布式版本管理系统，由此萌发了撰写此文的想法

集中式版本管理系统

在集中式版本管理系统中，每个开发者在其本地都有一个包含所有项目文件的目录。开发者在本地环境中对项目做出修改之后，将代码提交到某台服务器（服务器配置在公司内网中），开发者在执行更新操作（update）的同时会从该服务器上捡取出其他开发者所做的修改。中央服务器上存储着版本库所有版本。因此，所有并行开发的分支，以及各种被命名或标记的版本都将会被集中管理

分布式系统

在分布式系统中，开发者环境与服务器环境之间时没有分隔的。每个开发者都有一个“克隆（Clone）”到本地的一个版本库，以及用于当前文件操作的工作区。开发者所作的修改，会被载入成一次次新版本提交（commit），先将修改提交到本地的版本库中，然后，通过push和pull命令，将修改从一个版本库传送到另外一个版本库中。

区别

在笔者看来，Git与SVN之间最大的区别，即使用SVN时，用户所作的对于项目的修改，需要跟中央服务器上的版本库进行交互发布新版本。笔者在公司进行开发的时候，一般是先将服务器上的项目文件Checkout到本地，然后进行开发，再提交到公司的服务器上。

而在Git使用中，不存在“中央服务器”的概念，不同环境下的版本库其实是“同等”的，在项目开发的过程中，一般先Clone远程的版本库至本地，然后在本地进行的修改，使用commit命令更新本地版本库，然后使用push命令将更新同步到团队开发人员约定的某个版本库上。

值得一提的是，在集中式版本管理系统中，update命令是将本地的版本更新为服务器上的版本，笔者在第一次使用SVN提交自己的修改到服务器上时，就犯了这个错误，导致自己开发了将近一周的项目被“回滚”到原始版本。在《Git学习指南》这本书中也有提到这一点。