代码提交和同步——从update和commit说起

    每当我们开始一个新的修改之前，首先要做的是从代码库中提取出一份最新的副本(通过update操作完成)；在本地修改、粗调之后，则应尽快将代码提交回代码库(通过commit操作完成)。

    基本的update和commit操作流程如下图所示：

    这两项操作也解决了日常开发大约80%的问题。绝大多数情况下，这部分的工作是相当简单的，除非出现两个开发者同时修改同一个文件的情况，例如，两个开发者同时地修改了同一个文件的同一个版本，这种情形称为冲突：

    可能开发者B的动作比较快，或者，修改的东西比较简单，于是他首先提交。在A、B从代码库中提取代码时，最新版本是1.1，于是，B提交的版本被版本控制系统命名为1.2。

    但不久，A想要提交代码，版本控制系统将拒绝他的提交，因为他的修改基于代码的1.1版，而目前的最新版本已经是1.2了。cvs提供了自动合并功能，允许在两个人修改的不是同一行代码的前提下，自动合并本地修改和最新的代码，当然，如果赶上两个人同时修改同一行代码的情况，cvs也会非常“聪明”地把两个“英雄所见略同”的地方合并。

    但如果两个人恰好都修改了同一行代码，而且改的不一样怎么办？cvs会告诉后一个提交的开发者发生了这样的情况，并且要求他解决问题。代码中存在的差异将以<<<和>>>标记出来，以方便进行修改。

    简单说来，当发生冲突时，我们通常约定由后一个提交者解决冲突——当然，他可以选择忽略这些冲突，但这些操作都会被记录，更何况，统计显示，同时将一行代码修改为两种不同的样子这样的情况在实际开发中很少出现。于是，修改流程继续，如下图：

    极端情况下，可能出现多个开发者同时修改同一个文件的问题。这一问题基本上可以按照上述的方法解决。当然，为了避免发生这样的情形，在设计的时候就应该让每个人工作的代码尽可能地不重叠。

    下面是非常基本的cvs update/commit操作规范：

    简单的cvs操作约定

    修改文件之前首先update。这意味着修改时的版本尽可能新，一旦发生冲突，解决它的工作量会比较小。

    及时commit。本地代码与代码库中的代码差异越小，别人合并的难度也就越小(他们有比较大的概率能够拿到新的版本)

    将不同的功能单元修改分开commit。一方面，这样做能够尽早地commit，减少别人合并的难度；另一方面，由于cvs提供了回退到先前版本的能力，一旦由于某项功能修改造成问题，也很容易将那次修改的内容，而不是整个修改回退到正常的代码。

    同一功能涉及的所有代码一次commit。不希望将涉及同一功能修改的代码分开commit，因为这会给日后的追踪带来麻烦。

    先调试后提交。这将减少别人不会因为同步了中间结果引发问题，甚至发生提交冲突的可能。

    写清commit log(提交日志)。cvs中允许保存commit log，在这里可以写为什么进行代码的修改，以及进行了什么样的修改，清楚的commit log能够帮助其他开发者在不仔细阅读代码的情况下了解修改的内容，从而极大地提高开发效率；另一方面，这些日志对于开发者自己，以及整个开发团队，都是非常宝贵的财富。

    同步代码(update)和提交代码(commit)占到了cvs日常操作的80%以上。从上面的介绍我们可以看出，仅仅依靠这两项非常简单的功能，cvs就能极大地改善开发流程，并提高软件工程的可控性。简单地说：

    全体开发者使用同一个中央代码库，从而消除了由于来回复制文件导致的不一致。

    发生冲突时，后提交的开发者必须解决它。这名开发者能够知道是谁引入了冲突，他可以自己解决冲突，也可以与引入冲突的开发者商量如何解决冲突。

    测试可以贯穿编码过程的始终，任何时候引入的新问题都能够被及时追踪、快速定位，从而更有效地解决。

    由于存在中央代码库，代码审核人员和每日构建人员能够及时地了解代码是否存在问题，并帮助项目经理保证开发进度。

    有助于帮助开发人员养成严谨的工作习惯——规则要求他们将尽可能地提交正确的代码，并且每个修改必须写commit log进行说明。

    有助于建立更公平的工作质量评估机制。 cvs能够记录每个人完成的实际工作量，包括他们因为修正问题等等所作的劳动，以及他们完成代码的质量情况。这样，管理者能够为优秀的开发人员提供更好的工作机会、报酬，等等，这对于鼓舞整个团队的士气、提高开发人员的工作积极性都是非常有益的。

    促进开发人员之间的交流。尽管cvs本身无法代替交流，但commit log，以及cvs系统获取任意版本之间差异的能力，能够帮助开发人员了解对方的想法，并促进他们共同提高。

    降低程序开发人员的门槛。由于提供了许多非常方便的协同开发手段， 使用cvs能够减少协同开发所需要的磨合期，同时，不同层次的开发者之间由于能够进行经常性的沟通，从而把编码过程从技能型工作向熟练性工作又推进了一步。这意味着高层次的开发人员能够去进行更能发挥他们特长的工作，而新手则可以很快地融入到日常的开发活动中来，从而提高劳动生产率，降低开发成本。

    编码过程中的沟通纽带——commit mail

    cvs是一项开放性很强的工具，它可以被非常容易地订制。一般来说，cvs服务器会架设在一台Unix主机上(我们推荐使用FreeBSD)，通过使用脚本语言(例如，Perl)，cvs能够完成一些额外的功能。

    commit mail是commit log在邮件系统上的延伸。下面是一封典型的commit mail，它来自FreeBSD开发团队：

    phk 2003/10/21 23:32:20 PDT

    FreeBSD src repository

    Modified files:

    sys/geom geom_io.c

    Log:

    Forgotten commit: If a provider has zero sectorsize, it is an

    indication of lack of media.

    Tripped up: peter

    Revision Changes Path

    1.50 +3 -6 src/sys/geom/geom_io.c

    我们看到，上面的这封commit mail中提到了开发者(phk)、提交时间(太平洋时间2003年10月21日23:32:20)、涉及的代码库名字(FreeBSD src repository)、修改过的文件(sys/geom的geom_io.c)以及commit log。最后，commit log还提到了提交后文件的最新版本(1.50)，修改规模(+3 -6)以及代码的实际路径。

    实现上面的功能并不复杂，实际上，您只需要下载一套经过定制的FreeBSD cvs代码库(压缩包不超过40KB)，并作少量的调整，就能够直接使用这些功能(我们将在不久以后发布这些内容)。进行这些订制甚至不需要基本的Perl和C/C++常识就能够完成——当然，我想这样的常识对于软件开发人员来说，并不算是很高的要求。

    commit mail可以通过邮件列表发给全体开发者。许多大的软件公司，以及开放源代码团体，都采用这样的方式来协调开发活动。