version control 软件配置管理，版本控制，也被称为修订控制或源控制，[1]是对文档的更改，管理计算机程序，大型网站，以及其他信息集合。更改通常由数字或字母代码标识，称为“修订号”，“修订级别”或简称“修订版”。例如，初始文件集是“修订版1”。进行第一次更改时，结果集为“版本2”，依此类推。每个修订都与时间戳和进行更改的人相关联。可以比较，恢复和某些类型的文件的修订，
组织和控制修订的逻辑方法的需要几乎与编写存在一样长，但在计算时代开始时，修订控制变得更加重要和复杂。书籍版本和规范修订版的编号可以追溯到仅印刷版时代。今天，最有能力（以及复杂）的版本控制系统是在软件开发中使用的系统，其中一组人可以同时对相同的文件进行更改。
概述：
版本控制系统（VCS）通常作为独立应用程序运行，但版本控制也嵌入在各种类型的软件中，如文字处理器和电子表格，协作Web文档[2]以及各种内容管理系统，例如维基百科的页面历史。版本控制允许恢复文件到以前的版本，这是编辑人员跟踪对方的编辑，纠正错误，并抵御破坏和批判的能力，垃圾邮件的维基。
在计算机软件工程中，修订控制是跟踪和控制源代码更改的任何类型的实践。 软件开发人员有时会使用修订控制软件来维护文档和配置文件以及源代码。
当团队设计，开发和部署软件时，通常会将同一软件的多个版本部署在不同的站点中，并使软件开发人员同时处理更新。 软件的错误或特征通常仅出现在某些版本中（因为某些问题的修复以及程序开发时引入的其他问题）。因此，出于定位和修复错误的目的，能够检索和运行不同版本的软件以确定问题发生在哪个版本中是至关重要的。可能还需要同时开发两个版本的软件：例如，一个版本修复了错误，但没有新功能（分支）），而另一个版本是处理新功能（主干）的地方。
在最简单的层面上，开发人员可以简单地保留程序的不同版本的多个副本，并适当地标记它们。这种简单的方法已经在许多大型软件项目中使用。虽然这种方法可行，但由于必须维护许多几乎相同的程序副本，因此效率很低。这需要开发人员进行大量自律，并且经常会导致错误。由于代码库是相同的，它还需要向一组开发人员授予读写执行权限，这增加了管理权限的人员的压力，这样代码库就不会受到损害，这增加了更多的复杂性。因此，开发了一些自动化部分或全部修订控制过程的系统。这确保了版本控制步骤的大部分管理隐藏在幕后。
此外，在软件开发，法律和商业实践以及其他环境中，团队编辑单个文档或代码片段变得越来越普遍，团队成员可能在地理上分散，可能追求不同甚至相反的兴趣。 。在这种情况下，跟踪和说明文档和代码更改所有权的复杂版本控制可能非常有用甚至是必不可少的。
修订控制还可以跟踪配置文件的更改，例如通常存储在Unix系统中/etc或/usr/local/etc上的系统。这为系统管理员提供了另一种轻松跟踪所做更改的方法，以及在需要时回滚到早期版本的方法
结构：
版本控制管理一组数据随时间的变化。这些变化可以以各种方式构建。
通常，数据被视为许多单个项目（例如文件或文档）的集合，并且跟踪对单个文件的更改。这符合关于单独文件的直觉，但在身份更改时会导致问题，例如在重命名，拆分或合并文件期间。因此，某些系统（例如git）会考虑整体更改数据，这对于简单更改而言不太直观，但可以简化更复杂的更改。
当修改受版本控制的数据时，在通过签出检索之后，这通常不会立即反映在修订控制系统中（在存储库中），而是必须检入或提交。修订控制之外的副本称为“工作副本”。举一个简单的例子，编辑计算机文件时，编辑程序存储在内存中的数据是工作副本，通过保存提交。具体地说，可以打印出文档，手动编辑，然后稍后手动将更改输入计算机并保存。对于源代码控制，工作副本是特定修订版中所有文件的副本，通常存储在开发人员的计算机本地;[注1]在这种情况下，保存文件只会更改工作副本，并且检查存储库是一个单独的步骤。
如果多个人正在处理单个数据集或文档，则它们隐式地创建数据的分支（在其工作副本中），因此出现合并问题，如下所述。对于简单的协作文档编辑，可以通过使用文件锁定或简单地避免处理其他人正在处理的同一文档来防止这种情况。
修订控制系统通常是集中的，具有单个权威数据存储，存储库以及参考此中央存储库完成的检出和签入。或者，在分布式版本控制中，没有单个存储库具有权威性，可以检出数据并将其签入任何存储库。当检入不同的存储库时，这被解释为合并或补丁。