version control

what

版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了已录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。

具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发产生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。

版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段。还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持，这些辅助数据将能直接统计出过程数据，从而方便软件过程改进活动的进行。对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。

how

版本控制基本流程如下：

(1)创建配置项。

项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。

(2)修改状态为“草稿”的配置项目。

项目成员使用配置管理软件的Check in/check out功能，可以*修改处于“草稿”状态的配置项，版本号格式为0.YZ。

(3)技术评审或领导审批。

如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理(或上级领导)的审批。若配置项通过了技术评审或领导审批，则转向下一步·否则转回上一步。

(4)正式发布。

配置项通过技术评审或领导审批之后。则配置项的状态从“草稿”变为“正式发布”，版本号格式为X.Y。

(5)变更。

修改处于“正式发布”状态的配置项，必须按照“变更控制流程”执行。

why

你的项目团队为什么需要一个自动化的版本控制工具？有以下几个理由：

• 它将跟踪项目的历史和演变，所以你不必亲为。对于项目的每个变化，都会有一个日志来记录谁做的修改，为什么修改，什么时候进行的修改，修改了些什么。

• 当你与其他人合作时，版本控制软件使你们更便于协作。例如，当人们或多或少同时进行可能不兼容的更改时，软件将帮助你识别和解决这些冲突。

• 它可以帮助你从错误中恢复。如果您进行的更改后来证明是错误的，您可以将一个或多个个文件还原到一个早期的版本。事实上，一个真正好的版本控制工具甚至可以帮助你有效地确定问题是何时引入的（详见“找出错误的源头”）。

• 可以让你并行地工作，并管理你在项目中多个版本之间的跳转。

一个项目，无论只有你一个人，还是还有几百个别人，这些理由中的大部分都成立——至少在理论上。

在两种不同规模的项目（“个人”和的“大型团队”）中，版本控制的可行性关键在于它的使用收益和使用开销之比。一个难以理解和使用的版本控制工具必定会加大开销。

对于一个五百人的项目，在没有版本控制工具和方法的情况下，由于其自身的体量，有可能会立即崩溃。这种情况下，版本控制的开销几乎可以忽略不计，因为没有它，项目注定会失败。

另一方面，版本控制工具对于一个人的“快速上手”式开发看上去并不合适，因为其真正的使用开销与项目的总体开销相接近，是吗？

Mercurial独有地支持这两种级别的开发。由于容易上手，你可以非常轻松地在几分钟内学会基本知识，并在最小的项目中使用它来进行版本控制。它的简单性意味着不会有很多深奥的概念或命令序列需要你去掌握，而只需专注于你真正想做的工作。同时，Mercurial的高性能和点对点的特性又可以让您轻松的处理大型项目。

任何版本控制工具都不能挽救一个糟糕的项目，但是，选择一个好的工具能够对项目进展是否顺畅造成巨大的影响。