接上篇。上次讲到建立自己的沙盘。这是一个开源软件开发的小系列，简单介绍下一些经验和体会。

凡是有点规模的开发，都需要有源代码管理。实际上，即使是自己编个程序、写个脚本或文档，源代码管理也可以提供很多的便利。

源代码管理经历了几代的沿革和发展。从最初的单文件加锁和没有网络支持，发展到具有网络支持的集中式控制代码管理，现在这种方式还是占据不少的市场份额。在共同开发方面，集中统一式的管理要求你必须先合并（merge）后才能提交（commit）。代表性的统一式代码管理工具和产品有CVS，Subversion，TFS等。在统一式代码管理系统下，我们只有一个总代码库（repository）。

最近几年开始流行分布式源代码管理系统。跟传统的统一代码管理不同的一点是分散式代码库：即每一个开发员有会自己的代码库实例。代码被改动过之后，开发人员可以先提交到自己的实例上，然后合并。代表性的产品和工具有Bazaar，Git，和Mercurial。

我用过CVS，Subversion，Bazaar，和Git。我个人的经验是它们各有利弊，当然我没有build engineer的经历，所以我在这方面的经验并不丰富。Linus Torvalds几年前在股沟有一个关于Git的讲演。他讲得不错，有时间的话值得一看/听。当然用哪一个系统（中央vs分布）在很大程度上取决于开发团队的技术强项、熟悉程度、公司的目标和制度。不过现在从长远来看，分布式的源代码管理是大趋势。

插点花絮。Linus Torvalds（Linux的主创）和Monty Widenius（MySQL的主创）都是以瑞典语为母语的芬兰人。Linus讲基本上听不出外国口音的美式英语，个性比较高傲。Monty的英语口音比较重，但表达没问题。口音不可怕，能听懂，可以把意思说出来就好。

从开源的角度来看，用什么代码库和工具在很大程度上取决于这个项目放在什么平台上。如果你感兴趣的项目在Launchpad上，那你当然要花时间学好bzr，如果是在Github上，就要练习好git。当然如果你是一个项目的发起者，你就可以自己决定用哪个平台。现在比较流行的平台有Googlecode，Launchpad，Github，SourceForge等。Launchpad只用Bazaar；Github当然只有git;Googlecode支持Subversion，git和Mercurial（应当是三者选一）;SourceForge好像只支持CVS和Subversion。

不管哪个平台，特别是分布式代码系统的东西，很多情况下你需要通过ssh来和托管机器（hosting URL或机器）交流，这就需要你自己的ssh key。如果你还没有，可以通过Linux系统上的ssh-keygen来生成这个外向和私有的key。生成了自己的id_rsa和id_rsa.pub的key文件之后，要把它们保管好，因为那个id_rsa.pub的key会被提交到Github，Launchpad等地。而id_rsa.pub是外向的，我们可以用它来和私有的id_rsa来验明你的身份。

选中了源代码管理工具和托管的机器或平台，你可以自己建几个Utility的项目来练习一下，如果你对源代码工具不熟的话。像在Googlecode，Github，和Launchpad等地很容易就可以建立起自己的开源项目，你可以放进去自己常用的脚本和自己写得小工具等。这即可以保存自己的脑力劳动成果，也可以练习源代码工具的使用。实际上在开源领域里做，bzr/Launchpad，git/Github/Googlecode等都要熟悉。常用的命令如clone，commit，pull，push，status，log，revert，blame等要明白和会用。

当然你也要知道怎样用diff来做个补丁（patch），和怎样来贴别人提交的补丁。这包括只补一个文件，多个文件，和多个分散在不同文件夹里的文件。关于运用diff和patch，这些东西只要可以接触到Linux的机器就可以练练。

说起diff，有很多的GUI工具比较好用。在Windows上你可以用开源免费的WinMerge。在Linux上我有时会用kdiff3，比较喜欢。我以前在公司里用Mac的时候，听说苹果的FileMerge比较好用，但我没试过。如果你用git和Linux，那么gitk这个GUI工具非常好，观看历史，分支，标签等都一目了然。我上次和MariaDB的wlad在一起，他告诉过我一个不错的bzr的GUI工具，好像是在Linux上，但我忘掉是哪一个了。

之所以讲diff，是因为我感觉在任何提交（commit）之前，你要再读一下diff。我以为这是一个最佳实践。阅读其他程序猿的diff也是一个好主意，这样你会对同事和合作伙伴有更多的了解。这也是一个非正式的code review，你也可能学到不少东西。

其他最佳实践还有要舍得用标签（tags）。标签不占地方，特别是在分布式代码管理上，但它却可以提供一个简洁明了的记号，便于管理和分类。另外，在提交时要写好的、言简意赅的短评。不要只说“bug 123 fix”，简要告诉我bug 123是怎么回事和如何改正。当然能做到言简意赅最好，如果做不到，没关系，以后慢慢提高，但请宁多勿缺，如果自己写不短的话，长一点没关系。

当然，在提交之前至少要过自己的unit test，并提交test cases。还要过其他的测试。测试太重要，以后会专门来写一篇。