开源软件的参与及社区互动的一些体会和建议:熟悉源代码的管理方式和工具

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

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

源代码管理经历了几代的沿革和发展。从最初的单文件加锁和没有网络支持,发展到具有网络支持的集中式控制代码管理,现在这种方式还是占据不少的市场份额。在共同开发方面,集中统一式的管理要求你必须先合并(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。还要过其他的测试。测试太重要,以后会专门来写一篇。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.