前言
最近个人事情比较多（搬家、换工作、短暂休息）所以一直也没有顾得上博客更新，恰好最近收到一封邮件提醒了我。
也是时候写一篇文章来聊聊参与开源项目的事（最近也确实进入了笔荒期）。
ps:第一次收到这样的中秋节礼物，加上
Dubbo
社区的活跃及阿里的重视度，还在做
RPC
或微服务技术选型的朋友可以考虑
Dubbo
。
参与开源
现在具体来聊聊参与开源的事；
日常几乎所有的开发者都会享受到开源项目所带来的便利甚至是收益，受限于环境早在十几年前甚至几年前开源活动一直都是有国外开发者主导。
但这几年国内互联网公司逐渐国际化扩大影响力也很大程度的提高了我们的开发水平，以
BAT
为首出现了许多优秀的开源项目。
现在甚至参与开源项目还能另辟蹊径的拿到大厂
offer
，所以其实不少朋友都想参与其中，可能这事给人的第一感觉就不太容易，所以现在还卡在第一步。
具体步骤
以下是以我个人经验总结的几大步骤：
下面我会结合最近一次参与
Dubbo
的流程来具体聊聊。
发现问题或自荐 feature
首先第一步自然要搞清楚自己本次贡献的内容是什么？通常都是解决某个问题或者是提交一个新的
feature
；前者相对起来更加容易一些。
当然这个问题可以是自己使用过程中发现的，也可以是 Issues 列表中待解决的问题。
以本次为例，就是我在使用过程中所发现的问题，也提交了相关 Issue 并写了一篇文章记录并解决了该问题：
What？
一个 Dubbo 服务启动要两个小时！
值得注意的是在提交 Issue 之前最好是先在 Issue 列表中通过关键字检索下是否已经有相关问题，避免重复。
同时提交之后也许社区会进行跟进，被打上
invalid
标签认为不是问题，或者是使用姿势不对也是有可能的。
fork 源码，本地开发
当确定这是一个待修复的问题时就可以着手开发了。
首先第一步自然是将源码拷贝一份到自己仓库中。
接着只需要 clone 自己仓库中的源码到本地进行开发。
先回顾下我遇到的这个问题。
简单来说就是启动
Dubbo
服务非常缓慢，经过定位是
main
线程阻塞在了获取本机 ip 处。
所以当时我提出的方案是：在获取本机 ip 时加上超时时间，一旦超时便抛出异常或者是再次重试，但起码得有日志方便用户定位问题。
问题是主线程会一直阻塞在此处
InetAddress
.
getLocalHost
().
getHostAddress
()
，但又需要知道它阻塞了多久才好判断是否超时。
所以只能再额外开启一个线程，定时去检测
main
线程是否已经完成任务了，以下便是我第一次 pr 的内容。
这次的重点不是讨论这里具体的技术细节，所以简单说下步骤：
如何自测
开发完成后下一步就是自测，由于这类项目是作为一个基础包依赖于其他的项目才能运行的，所以通常我们还得新建一个项目来配合做全流程测试（单测除外）。
这里我觉得还是有几个小技巧值得注意。
第一个是版本号；因为在本地测试，所以需要使用
mvn clean install
将包安装到本地才能在其他项目中依赖进去进行测试。
但由于我们从官方拉出来的代码版本都已经发布到了 maven 中央仓库中（不管是 release 还是 snapshot），所以我们本地仓库中肯定已经存在这几个版本的 jar 包。
一旦我们执行
mvn clean install
将自己修改的代码安装到本地时，大概率是会出问题的（也可能是我姿势不对），这样就会导致新建的项目中依赖不了自己新增的代码。
所以我通常的做法是修改版本号，这个版本号是从来没有被官方发布到中央仓库中的，可以确保自己新增的代码会以一个全新版本安装到本地，这样我们再依赖这个版本进行测试即可。
不过再提交时得注意不要把这个版本号提交上去了。
发起 pull request
自测完成后便可发起
pull request
了，不要大意，这里还得有一个地方需要注意，那就是代码换行符的问题。
一旦换行符与源仓库的不一致时，
git
会认为这次修改是删除后重来的，这样会给
code review
带来巨大的麻烦。
就像这样，明明我改动的行数并不多，但
git
确认为你是推翻了重来，导致审核起来根本不知道你改了哪些地方。
最简单的方法就是设置自己
git
的全局配置，可以参考这里。
# 提交时转换为LF，检出时转换为CRLF
git config --global core.autocrlf true
# 提交时转换为LF，检出时不转换
git config --global core.autocrlf input
# 提交检出均不转换
git config --global core.autocrlf false
确认没问题后便可点击这里发起 pull request，后面按照引导执行即可。
当然各个项目之间还会有自己定制的贡献流程，最好就是查看官方的贡献指南。
