一、软件打包宣布-概述

测试完成以后的下一步就要斟酌如何进行程序发布了，程序发布的技术问题这里就不再做具体的解释，在这里重点讲一下如何对程序的版本进行详细的管理。

版本控制已经出现有些年头了。然而，我仍是会被人问起一些，诸如版本控制是什么或者它是如何工作的，这样基础的问题。本文会概括地解释版本控制解决的主要问题，并用简单的案例讲授如何进行详细的管理。

二、版本管理的基础定义：

版本节制（Version Control）的作用是追踪文件的变更。为什么须要版本把持？简略说，就是当你犯错了，能够很轻易地回到没出错时的状况。

你可能已经在人不知鬼不觉中，安排了自己的版本控制系统。比如，创建了类似下面这样的文件名：

* KalidAzadResumeOct2006.doc

* KalidAzadResumeMar2007.doc

* instacalc-logo3.webp

* instacalc-logo4.webp

* logo-old.webp

这就是软件中为什么有"Save As"命令的原因。它使得你可以在不损坏源文件的基础上，得到一个相似的新文件。文件的多版本保存是一个常见问题，通常的解决措施是这样的：

* 做一个文件备份（比如Document.old.txt）。

* 在文件名中加入版本号或日期（比如Document_V1.txt，DocumentMarch2007.txt）。

* 在多人编辑的环境下，共享一个文件目录，并且请求每个人编辑完以后，在文件上做出标识。

三、什么是版本控制系统（VCS）？

通过文件名辨认版本，对小型名目或者单个文件也允许行。然而对于济南软件开发来说，是不实用的。

你能想像吗，要是Windows操作系统的源文件，是在一个叫做"Windows2007-Latest-UPDATED!!"的共享目录中开发的，并且每个程序员都可以编辑，都有一个本人的子目录，那会发生什么情况？那么，Windows就基本不可能被制作出来。

大型的、频繁修正的、多人编写的软件项目，需要一个版本掌握体系（简称VCS，行话叫做"文件数据库"），追踪文件的变化，防止呈现凌乱。一个好的VCS应当做到以下多少点：

* 备份（Backup）和恢复（Restore）。文件的每一次编辑都得到保存，可以恢复到任意一个日期。需要2007年2月23日的版本？没问题。

* 同步（Synchronization）。让不同用户随时都能得到文件的最新版本。

* 短期撤销（Short-term undo）。文件被你搞乱了，怎么办？那就撤销编辑，回到最近一次的无错误版本。

* 长期撤销（Long-term undo）。有时候，你会过了良久才发现出错了。假如你想撤销一年前的一次编辑，怎么办？那就去取回一年之前的那个版本。

* 追踪修改（Track Changes）。文件的每一次编辑，你都可以写下注解，说明编辑的起因。（这些信息贮存在VCS中，而不是文件中。）这样就很容易看出，长期中文件变化的脉络和原因。

* 追踪权限（Track Ownership）。VCS会记录每一次提交新版本的用户名。这样就容易追踪义务。

* 实验功效（Sandboxing）。当你对文件做出重大变革时，你可以把编纂内容临时性地保留在一个独自的区域，一直进行测试跟除错。等到确认准确当前，再参加主版本。

* 分支（Branching）和合并（merging）。分支功能可以看成是一个更大的测试版本。你将全部的代码做一份拷贝，而后再起一个独破的名字，追踪其变化，与原版本脱离关联，这就是分支。以后，你还可以将分支版本再并入源版本，这就是合并。

固然共享文件夹操作起来更疾速和简单，但是它做不到上面这些功能。

大多数VCS都有下面一些独特的概念，不外名字可能会稍有不同。

四、版本控制的详细案例

目前有良多不同类型的版本控制系统（Version Control System， VCS）。一些VCS，比方Subversion和CVS，以中央仓库（repository）为核心进行架构。此外，还有散布式的VCS（Distributed VCS，DVCS）， Git 和 Mercurial 是两个早先涌现的DVCS。然而，在上述两品种型的环境中，通常会有一个“指定的”中心仓库。对应地，好比一个Subversion服务器或者一个GitHub仓库。下面会基于这个场景进行图示阐明。那么让咱们开端吧。

在开发者拷贝到本机之前，服务器需要创立一个仓库。创建初始仓库会因为产品不同而有所差异。从当初起，你所要晓得的就是，在服务器上有一个初始空间。我把这个版本称作版本“A”。

现在，每个开发者（开发者1和开发者2）都会拷贝版本“A”到他们本地电脑。再一次地，从服务器拷贝的进程会由于产品不同采取的技巧会有所差别。

每个开发者会在他们的本地拷贝长进行开发。他们的本地拷贝基于版本“A”。然而，因为他们应该不会做同样的开发，因此他们的版本会有所差别。因而，会有2个以上的版本会同时被创建，比如版本“B&rdquo,电脑公司管理系统;和版本“C”。

开发者1首先完成了她的工作并提交到服务器。服务器上确当前版本被更新成版本“B”。

开发者2现在完成了他的工作并试图提交到服务器。然而，这是服务器告诉他基于开发的版本已经发生转变。这也是为什么采用版本控制的重要原因之一。这个特征是对网络共享代码然后由开发者手动更新的一个逾越式发展，这确保了之前的编辑不被新的修改笼罩。

开发者2必需首先取得所有版本“B”的变化，并合并到他的修改中，然后才可以提交到服务器。这个过程听起来有些庞杂。然而，大多数古代的版本控制系统非常高级，可以主动在开发者的本地拷贝上完成合并。有几种情形会发生抵触（例如：开发者1和开发者2同时修改了统一个文件的同一行）。这就是一些VCS产品比其他更高等的处所。不管如何实现合并，现在开发者2在他们的本地系统上同时混杂了版本B和版本C。

现在开发者2可以提交他的版本到服务器。

这是一个版本控制的基本。通过留神察看图中服务器的连线可以发明版本控制的原理。服务器记载了所有先前的版本包含发生的变化，什么时候产生以及由谁进行修改。当需要进行代码回溯或者引入其余bug时，这个记载可能解除窘境。