2.3　现场版本控制

所谓现场版本控制，就是在客户现场或在产品部署的现场进行源代码的修改，并在修改过程中进行版本控制，以便在完成修改后能够将修改结果甚至修改过程一并带走，并能够将修改结果合并至项目对应的代码库中。

1.SVN的解决方案

如果使用SVN进行版本控制，首先要将服务器上部署的产品代码目录变成SVN工作区，这个过程不仅不简单，而且会显得很繁琐，最后将改动结果导出也非常不方便，具体操作过程如下。

（1）在其他位置建立一个SVN版本库。

$svnadmin create/path/to/repos/project1

（2）在需要版本控制的目录下检出刚刚建立的空版本库。

$svn checkout file:///path/to/repos/project1.

（3）执行添加文件操作，然后执行提交操作。这个提交将是版本库中编号为1的提交。

$svn add*

$svn ci-m "initialized"

（4）开始在工作区中修改文件并提交。

$svn ci

（5）如果对修改结果满意，可以通过创建补丁文件的方式将工作成果保存并带走。但是SVN很难针对每次提交逐一创建补丁，一般用下面的命令与最早的提交进行比较，以创建出一个大补丁文件。

$svn diff-r1＞hacks.patch

上面用SVN将工作成果导出的过程存在一个致命的缺陷，就是SVN的补丁文件不支持二进制文件，因此采用补丁文件的方式有可能丢失数据，如新增或修改的图形文件会丢失。更为稳妥但也更为复杂的方式可能要用到svnadmin命令将版本库导出。命令如下：

$svnadmin dump—incremental-r2:HEAD\

/path/to/repos/project1/＞hacks.dump

将svnadmin命令创建的导出文件恢复到版本库中也非常具有挑战性，这里就不再详细说明了。还是来看看Git在这种情况下的表现吧。

2.Git的解决方案

与SVN将产品部署目录转化为SVN的工作区相比，Git要更为简单，而且使用Git导出提交历史也更为简单和实用，具体操作过程如下。

（1）创建现场版本库。直接在需要版本控制的目录下执行Git版本库初始化命令。

$git init

（2）添加文件并提交。

$git add-A

$git commit-m "initialized"

（3）为初始提交建立一个里程碑："v1"。

$git tag v1

（4）开始在工作区中工作——修改文件并提交。

$git commit-a

（5）当对修改结果满意并想将工作成果保存带走时，可以通过下面的命令将从v1开始的历次提交逐一导出为补丁文件。转换的补丁文件都包含一个数字前缀，并提取提交日志信息作为文件名，而且补丁文件还提供对二进制文件的支持。下面命令的输出摘自本书第3篇第20章中的实例。

$git format-patch v1..HEAD

0001-Fix-typo-help-to-help.patch

0002-Add-I18N-support.patch

0003-Translate-for-Chinese.patch

（6）通过邮件将补丁文件发出。当然，也可以通过其他方式将补丁文件带走。

$git send-email*.patch

Git创建的补丁文件使用了Git扩展格式，因此在导入时为了避免数据遗漏，要使用Git提供的命令而不能使用GNU的patch命令。即使要导入的不是Git版本库，也可以使用Git命令，具体操作请参见本书第7篇第38章中的相关内容。