介绍
我建议讨论组织版本控制系统的目的和各种方式。
版本控制系统
版本控制系统主要是一种工具，而工具旨在解决特定类别的问题。因此，版本控制系统是一个
随时间记录对一个文件或一组文件的更改，并允许您稍后还原到特定版本的系统。我们想要灵活地管理某些文件集，并在必要时回滚到某些版本。您可以撤消对该文件的某些更改，回滚其删除操作，查看谁进行了更改。通常，版本控制系统用于存储源代码，但这不是必需的。它们可用于存储任何类型的文件。
如何存储不同版本的文件？人们并没有立即使用诸如版本控制系统之类的工具，它们本身可能会大不相同。可以使用良好的旧复制粘贴，本地，集中式或分布式版本控制系统解决提出的问题。
复制粘贴
一种适用于此问题的众所周知的方法可能如下所示：我们将使用文件名filename_ {version}命名文件，可能还会增加创建或修改时间。
此方法非常简单，但是容易出现各种错误：您可能会意外地更改错误的文件，可以从错误的目录进行复制（毕竟，这是此模型中文件的传输方式）。
本地版本控制系统
版本控制系统开发的下一步是创建本地版本控制系统。它们是一个简单的数据库，其中记录了文件中所有更改。
此类系统的一个示例是RCS版本控制系统，该系统于1985年开发（最后一个补丁于2015年编写），并在保持版本控制的同时存储文件（补丁）中的更改。这些更改中的一组可以恢复文件的任何状态。RCS随Linux一起提供。
本地版本控制系统可以很好地解决问题，但是它的问题是主要属性-本地性。它根本不打算集体使用。
集中式版本控制系统
集中版本控制系统旨在解决本地版本控制系统的基本问题。
为了组织这样的版本控制系统，使用了包含所有文件版本的单个服务器。访问此服务器的客户端从此集中存储库获取。多年来，使用集中式版本控制系统一直是标准。这些包括CVS，Subversion，Perforce。
由于单个服务器，这些系统易于管理。但是同时，集中式服务器的存在会导致以服务器本身的形式出现单点故障。如果禁用此服务器，则开发人员将无法下载文件。最坏的情况是服务器的物理损坏（或硬盘崩溃），这会导致代码库丢失。
尽管SVN的流行方式已经过去，但有时还是存在逆向过程-从Git过渡到SVN。关键是SVN允许选择性检出，这涉及仅从服务器下载一些文件。使用单一存储库时，这种方法越来越受欢迎，这将在后面讨论。
分布式版本控制系统
分布式版本控制系统用于消除单点故障。它们暗示客户端将自己下载整个存储库，而不是下载客户端感兴趣的特定文件。如果存储库的任何副本失效，那么这不会导致代码库丢失，因为可以从任何开发人员的计算机上将其还原。每个副本都是数据的完整备份。
所有副本都是相同的，并且可以彼此同步。这种方法与主-主复制非常相似（确实如此）。
这种类型的版本控制系统包括Mercurial，Bazaar，Darcs和Git。最后一个版本控制系统将在下面详细讨论。
git历史
在2005年，版本控制公司BitKeeper与Linux内核社区断开了联系。然后，社区决定开发自己的版本控制系统。新系统的主要价值是：完全分散，速度快，架构简单，对非线性开发的良好支持。
结论
我们研究了组织版本控制系统的方法，讨论了解决分配给这些系统的任务的选项，讨论了每种版本的优缺点，并了解了Git版本控制系统的历史。
