参与 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 的代码：

c 复制代码

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 语言后：

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。