参与 GitHub 开源项目 Canal:从 Bug 修复到 Pull Request
简述
GitHub 对于程序员而言并不陌生,我们常常在这里寻找各种开源项目。
然而,当我们发现某个项目存在 Bug 时,通常的做法是提交 Issue 并静静地等待作者修复。
实际上,更推荐的方式是 Fork 该项目,自行修复 Bug 并向项目提交 Pull Request(PR)。这不仅符合开源精神,还造福了所有使用该项目的人。
那么,如何实际参与 GitHub 上的开源项目呢?本文将以作者实际工作中的场景为例,详细介绍参与 GitHub 开源项目的步骤。
Canal Bug
在工作中,我经常使用 MariaDB(11.2) 数据库,并使用 Canal 将 MariaDB 的增量数据变更同步到 Kafka。
Canal 是阿里巴巴旗下的一款开源项目,使用 Java 开发,基于数据库增量日志解析,提供 MySQL 和 MariaDB 的增量数据订阅和消费。
在测试环境验证 Canal 订阅 MariaDB Binlog 的过程中,发现了一些报错:
这些问题在生产环境是无法容忍的。幸运的是,在测试环境发现了这个问题,但如果只是向 Canal 官方提交 Issue等待修复,时间肯定不够。
所以,我们需要尝试自己修复这个 Bug。
我相信这样的场景多多少少每一位开发者都遇见过,我们享受了开源软件的便利,这个时候我们需要站出来奉献开源了[狗头]。
尝试修复
通过查看相关的错误堆栈,找到了 Canal 上的关键代码:
Canal 兼容解析 MariaDB 中的 Binlog 并没有 131 这个事件,所以导致解析 Binlog 报错了。
通过查看 MariaDB 官方 GitHub 项目,我们可以发现 Q_CHARCTER_SET_COLLATIONS 这个事件在 Buffer 中的操作。
同时,我们也可以从 MariaDB 的 Binlog 解析中找到这个原始语句:
修复 Bug
修复这个 Bug 无非就是加一个 Q_CHARACTER_SET_COLLATIONS(131)事件,然后根据事件的大小,在Buffer中进行一些位移操作。
- MariaDB 的代码:
case Q_CHARACTER_SET_COLLATIONS:
{
const uchar *pos0= pos;
CHECK_SPACE(pos, end, 1);
uint16 count= *pos++;
CHECK_SPACE(pos, end, count * 4);
pos+= count * 4;
character_set_collations= Lex_cstring((const char *) pos0,
(const char *) pos);
break;
}
- 转换为 Java 语言后:
case Q_CHARACTER_SET_COLLATIONS : {
int count = buffer.getUint8();
buffer.forward(count * 4);
break;
}
本地修改后、打包测试,Binlog 被成功解析了。
贡献社区
很遗憾的是,本文分享的时候,该 Bug 已经被作者给修复了,但是我希望这篇文章能带给所有使用 GitHub 开源软件的用户一些不一样的感悟。
下面还是走完所有提交 PR 的流程:
- 将 Canal 项目克隆到自己的仓库
- 修改代码后推送,在自己 Fork 的项目中点击 “New pull request”
- 选择自己的分支,以及要合并到 Canal 官方分支
- 写必要的信息后,成功创建 PR,之后等待作者审核合并
总结
GitHub是开发者接触最多的平台之一,最初我对 GitHub 并不理解,它不仅是一个代码仓库,还是无数开源软件社区的承载者。我们是社区中的受益者,也可以回馈社区。
以上就是我对于如何参与 GitHub 的思考和实际操作,希望这篇文章能够让您更好地理解和应用 GitHub。