5. 管理程序的历史

在程序开发的过程中，程序是一步步不断在演变中的。新的功能不断加入，错误的地方不断被修正。这每一步都包含很多有用信息。源程序管理系统 (Source Code Management, SCM) 能帮助我们保留和管理这些信息。保留和管理历史信息是软件/程序版本控制 (Version Control/Revision Control) 的前提。

当程序开发进行到一个阶段，我们通知 Git 请你记录下我这一步。这个动作称为提交 (commit, verb)，提交的内容也称提交 (commit, noun)。有趣的是英文和中文里提交 (commit) 这个词都可以被用做动词和名词。中文翻译成提交我不是很满意，但是目前没有好的词。

Git 的提交往往一组文件，而不单个文件一个提交。它的好处是使得每个提交成为一个单元，比较容易管理。比如一个提交改了数个文件，如果你要取消这个提交，Git 自动处理所有文件。你无需一个个文件去挑出来。除了老式的 CVS 和Source Safe，现在比较新的源程序管理系统都是一样提交一批文件。Subversion 也用提交 (commit) 同时作为提交动作和提交的内容。而Mercurial 提交动作用 commit，提交的内容则叫变化集 (change set)。

当我们保存一些编程的步骤后，Windows下就可以用 Git Extensions 的浏览 (browse) 屏幕回顾和查看程序的历史了。

屏幕的上半是程序历史上的所有步骤，也称提交(commit)的列表。屏幕的下半是选中的提交的具体信息。它分成三页分别来显示提交的详细内容，提交时完整的文件结构(file tree)，以及与上次提交之间的差别(diff)。用颜色来显示文件的差别(diff)很容易阅读。对应的Git命令是git log和git diff。如果用命令行可就没有图形界面这么直观了。

记录程序的历史是任何一个版本控制软件都能做的基本功。CVS，Source Safe，Subversion，TFS(Microsoft Team Foundation Server)，Mercurial 无一例外。Git有什么独特之处？Git的好处在于轻便。它只需要普通的执行程序，不需要安装服务器。如果你是单机小规模程序开发，装个Source Safe很简单实用。因为单机编程轻便最重要。单机上装个 CVS，Subversion，TFS 似乎太累赘。倒是Source Safe也是很轻便的。在众多反对Source Safe的浪潮中，有时候我会挺它，因为冲着它的轻便。个人简单使用的情况问题不大。但是如果功能需求复杂了Source Safe似乎缺点大于优点，如果讲成故事大概负面的多。相反Git既轻便，而且小到单机规模，大到全世界上百人同时做Linux核心开发。选用 Git 对于各种规模的开发团队应该都没有问题。

Git的提交还有个不同寻常的功能，它可以被施加到其它分支上。比如我有两个分支(branch)，这两个分支暂时无法合并(merge)，而第二个分支需要第一个分支里的一个提交所做的改动。这时候我可以用Git的Cherry Pick(采草莓)，从第一个分支的一堆提交中采出一个来施加到第二个分支。

这样自然就牵涉到如何给提交写注释的问题。在老式的版本管理系统中，我们常常会为一个阶段做提交。比如一个提交被注释为“加入了jQuery”。它表示到提交的那个时刻你做到什么程度了。在老式的版本管理系统里也就只能做到记录下这一步。当时Git不同，在Git里这个提交有可能可以被用到其它分支，所以通常可以注释成“加入jQuery”。查看程序历史的步骤，你就会看到一个可以重复利用的步骤。如果你的程序历史是一步步具体的做法，而不仅仅是一本哪天做到什么程度的流水帐，它就有重复利用的价值了。

不过这样打造历史是举手之劳呢，还是需要花费额外时间精力以至于不大值得去做。这个问题我还在进一步摸索中。建议读者也加以思考。

最终无论你如何组织你的程序的历史，它在Git Extensions中都将一目了然。