17 源码控制

进步远非由变化组成，而是取决于好记性。不能记住过去的人，被判重复过去。

　　——George Santayana, Life of Reason

　　我们在用户界面中找寻的一个重要的东西是UNDO键——一个能原谅我们的错误的按钮。如果环境支持多级撤消（undo）与重做（redo），那就更好了，这样你就可以回去，撤消几分钟前发生的事情。但如果错误发生在上周，而你那以后已经把计算机打开关闭了十次呢？噢，这是使用源码控制系统的诸多好处之一：它是一个巨大的UNDO键——一个项目级的时间机器，能够让你返回上周的那些太平日子，那时的代码还能够编译并运行。

　　源码控制系统（或范围更宽泛的配置管理系统）追踪你在源码和文档中做出的每一项变动。

更好的系统还能追踪编译器及OS版本。有了适当配置的源码控制系统，你就总能够返回你的软件的前一版本。

　　但源码控制系统（SCCS）能做的远比撤消错误要多。好的SCCS让你追踪变动，回答这样的问题：谁改动了这一行代码？在当前版本与上周的版本之间有什么区别？在这次发布的版本中我们改动了多少行代码？哪个文件改动最频繁？对于bug追踪、审计、性能及质量等目的，这种信息非常宝贵。

　　SCCS还能让你标识你的软件的各次发布。一经标识，你将总是能够返回并重新生成该版本，并且不受在其后发生的变动的影响。

　　我们常常使用SCCS管理开发树中的分支。例如，一旦你发布了某个软件，你通常会想为下一次发布继续开发。与此同时，你也需要处理当前发布的版本中的bug，把修正后的版本发送给客户。（如果合适）你想要让这些bug修正合并进下一次发布中，但你不想把正在开发的代码发送给客户。通过SCCS，在每次生成一个发布版本时，你可以在开发树中生成分支。你把bug修正加到分支中的代码上，并在主干上继续开发。因为bug修正也可能与主干有关，有些系统允许你把选定的来自分支的变动自动合并回主干中。

　　源码控制系统可能会把它们维护的文件保存在某个中央仓库（repository）中——这是进行存档的好候选地。

　　最后，有些产品可能允许两个或更多用户同时在相同的文件集上工作，甚至在同一文件中同时做出改动。系统随后在文件被送回仓库时对这些改动进行合并。尽管看起来有风险，在实践中这样的系统在所有规模的项目上都工作良好。

提示23
Always Use Source Code Control 总是使用源码控制

　　总是。即使你的团队只有你一个人，你的项目只需一周时间；即使那是“用过就扔”的原型；即使你的工作对象并非源码；确保每样东西都处在源码控制之下——文档、电话号码表、给供应商的备忘录、makefile、构建与发布流程、烧制CD母盘的shell小脚本——每样东西。我们例行公事地对我们敲入的每一样东西进行源码控制（包括本书的文本）。即使我们不是在开发项目，我们的日常工作也被安全地保存在仓库中。

源码控制与构建

　　把整个项目置于源码控制系统的保护之下具有一项很大的、隐蔽的好处：你可以进行自动的和可重复的产品构建。

　　项目构建机制可以自动从仓库中取出最近的源码。它可以在午夜运行，在每个人都（很可能）回家之后。你可以运行自动的回归测试，确保当日的编码没有造成任何破坏。构建的自动化保证了一致性——没有手工过程，而你也不需要开发者记住把代码拷贝进特殊的构建区域。

　　构建是可重复的，因为你总是可以按照源码将给定日期的内容重新进行构建。

但我们团队没有使用源码控制

　　他们应该感到羞耻！听起来这是个“布道”的机会！但是，在等待他们看到光明的同时，也许你应该实施自己私人的源码控制。使用我们在附录A中列出的可自由获取的工具，并确保把你个人的工作安全地保存进仓库中（并且完成你的项目所要求的无论什么事情）。尽管这看起来像是重复劳动，我们几乎可以向你担保，在你须要回答像“你对xyz模块做了什么？”和“是什么破坏了构建？”这样的问题时，它将使你免受困扰（并为你的项目节省金钱）。这一方法也许还能有助于使你们的管理部门确信，源码控制确实行之有效。

　　不要忘了，SCCS也同样适用于你在工作之外所做的事情。