>[success] # 版本控制系统 版本控制也是一种软件工程技巧，借此能在软件开发的过程中，**确保由不同人所编辑的同一程序文件都得到同步**，版本控制在软件开发中，可以帮助程序员进行代码的**追踪、维护、控制**等等一系列的操作 * **不同版本的存储管理** * **重大版本的备份维护** * **恢复之前的项目版本** * **多人开发的代码合并** * **记录项目修改的历史纪录** 这些功能很像我们经常使用的**大多数主流文本编辑器撤销功能**，我们可以利用`ctrl + z`回撤将我们修改错误输入的地方回撤，也可以用`ctrl + y`还原上次回撤时候的内容，这类功能满足上述说的**版本控制**场景 ***** 但在程序开发来说整体代码开发周期是一个长时间的工作，并且在回退的时候也许有可能是几周之前的代码，并不能像**文本编辑器撤销功能**，采用**每次改动自动保存**的形式来保留修改历史，将会导致改动历史非常频繁和无章可循，这样，历史代码的查找、阅读和回退就会很困难 ***** 因此开发过程中需要的是可以**主动提交改动**的机制，使用 `commit `命令把改动和对改动的描述信息提交，这次改动就被记录到版本历史中了。之后如果你希望回退到这个版本，就可以从**版本控制系统 VCS** 的历史日志中方便地找到它 >[success] # 集中式和分布式 在程序开发过程中的版本控制有两大类可以做到上面说到的结果`集中式（中央式）版本控制工具（svn）`和`分布式版本控制工具（git）`，版本控制上面已经解释了下面就是关于`集中`和`分布` * **集中式**：所有历史版本都在中央服务器上建立，本地客户端只是一个开发环境，开发完成需要推送到服务器生成历史版本，当需要回退到某个版本，也需要从中央服务器拉取，拉取的过程需要联网，**中央服务器不能出现故障**   * **分布式**:就是将每个开发者的本地客户端都是一个完整的仓库，都能记录历史版本信息，无需联网，也可以将生成的版本记录回退到某个版本中，客户端并不只提取最新版本的文件快照， 而是**把代码仓库完整地镜像下来，包括完整的历史记录**，每一次的**克隆**操作，实际上都是一次对代码仓库的**完整备份**   * 分布式的本地仓库、与集中式本地的区别。**本地仓库是带版本管理功能的，像可以离线做一些提交，回滚、查看历史、分支操作**，而**集中式的本地备份如脱离服务器则做不上面的这些操作** >[danger] ##### 分布式优缺点 * **优点** 1. 大多数的操作可以在本地进行，所以速度更快，而且由于无需联网，所以即使不在公司甚至没有在联网你也可以提交代码、查看历史，从而极大地减小了开发者的网络条件和物理位置的限制 2. 由于可以提交到本地，所以你可以分步提交代码，把代码提交做得更细，而不是一个提交包含很多代码难以 review 也难以回溯。 3. 集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。 * **缺点** 1. 由于每一个机器都有完整的本地仓库，所以初次获取项目（Git 术语：clone）的时候会比较耗时； 2. 由于每个机器都有完整的本地仓库，所以本地占用的存储比中央式 VCS 要高。 >[info] ## 使用分布式还是集中式场景 对于一般的程序项目而言，由于项目的大多数内容都是文本形式的代码，所以工程的体积都并不是很大，再加上文本内容自身的特点，VCS 可以利用算法来把仓库的体积极大地压缩。这就导致，在实际中，Git 等分布式 VCS 的仓库体积并不大，初次获取项目的耗时和本地仓库的存储占用都很小。所以对于大多数的程序项目而言，分布式 VCS 「尺寸大、初次下载慢」的问题其实并不严重。 不过也有一些例外，比如游戏开发。游戏的开发中有大量的大尺寸数据和媒体文件，并且这些文件的格式也不容易压缩尺寸，如果用分布式 VCS 会导致仓库的体积非常庞大。所以一些大型游戏的开发会选择中央式的 VCS 来管理代码。 >[info] ## 参考 [Git 原理详解及实用指南](https://juejin.cn/book/6844733697996881928)