本文共 1720 字，大约阅读时间需要 5 分钟。

前言

作为一名职业程序员，如果去除待遇，薪资等等的因素考虑，从纯技术的角度出发，如何才能达到一个比较高的境界呢，答案是与最顶尖的那一批人交流合作，当然，最顶尖的那批人很多几乎估计都不在身边，而且大多在国外。那么难道就没有办法了吗，不是的，不要忘了还有网络这个东西，可以通过社区，邮件进行交流，提出自己的想法。这些人往往活跃于许多开源社区，比如Apache.下面有很多的子项目，都是非常棒的系统。所以本文的1个关键词，开源社区。所以说，如果一个普通开发者能够向开源社区打出自己的patch(补丁)，并且此部分代码能够被merge进主干代码中，将会是一个开发者非常令人骄傲的一个事情。不要以为这个事情很难，开源社区的代码中也可能出现比如显示文字出错这样的低级错误，如果被你发现了，也是一个patch。总的一句话，能够向开源社区打patch的人，也许不能说明他又多强，但是一定程度上能说明他是具有钻研精神和思考能力的，毕竟大部人都还只是停留在使用这些开源社区的产品的层面上，对于内部复杂的设计与实现却只是略知一二。下面就来讨论一下，作为一个非Commiter，如何向开源社区提交代码，打出自己的patch。

打Patch的前提

首先打patch的一个前提条件是建立在你已经拥有分析和改造已有开源系统代码的能力之上。但是鉴于开源系统本身的复杂性，你可以专注于研究其中部分模块代码。比如Hadoop代码，你可以选择研究HDFS，或者说YARN，亦或者MapReduce这块，不管怎么说，你要拥有阅读和改造某块代码的能力。

Patch注意事项

Patch是如何打出的呢，patch的中文意思简称是”补丁”的意思，补丁类型的代码当然某种程度上指的是“修改”代码，包括修改代码和增删代码，也就是代码的变化之处，那么有什么工具可以知道代码的变化呢，git diff命令正好可以帮助我们解决这个问题。通过git diff > your desFileName命令就可以导出这个patch文件了，具体的命令读者可以自行查阅此命令的用法。但是这里又会有一个问题，patch打出来之后，只能说明这段patch代码能够运作正常，并不能代表这段patch遵守一定的规范。下面列出几个开源社区中对patch的一些约束，下面是一张Hadoop QA测试结果表。

其中注意下面几项：

1.patch必须是打在最新的代码之上的,否则会出现合并代码出错的情况,因为patch中会有每行代码的文件名和对应位置,一旦不是在最新代码上的修改必然会出错.

2.每行代码的最大长度不能超过80个字符,否则会包checkstyle error,所以建议的方法是每修改玩自己的代码以hadoop format格式文件的方式进行格式化操作.

3.多余空白行不能有.否则会报whitespace,多余空白行的意思指的是回车另起一行的时候,一般会多一行的空白行,要用delete建,把此行前面的空格符删去.

4.patch代码需要包含新的对应的测试代码,来证明你的patch的可行性.

5.patch的一般命名规范,issue序号+.00提交次序+.patch.类似如下:

OK,主要是以上的4点要求.

如何让Commiter采纳你的patch

当你把patch提交到开源社区的时候,一般Commiter会关注到你的issue,然后可能会迟些时间review你的patch,如果他认为不错,会给你提出意见,叫你修改patch代码,你应该积极响应commiter的回复,及时进行patch的更新,这会让人家对你产生好的印象,如果出现了下面类似+1的评语,代表他已经认同你的patch代码,基本上可以被合并进主干代码了.

OK,这基本就是代码提交的整个流程了,其实并不复杂,但是可能周期会比较长,因为代码必须要经过多次修改.

总结

最后希望作为国内的诸多程序员,能够向开源社区多做贡献,提升我们自身的影响力,毕竟这些东西目前都是外国的在做,不拘束于只是为了赚钱.下面放出我自己最近提交的2个issue给大家作为参考:

还有关于Yarn方面代码的分析请点击链接,后续将会继续更新YARN其他方面的代码分析。