跳到主要内容

参与 GitHub 开源项目 Canal：从 Bug 修复到 Pull Request

简述​

GitHub 对于程序员而言并不陌生，我们常常在这里寻找各种开源项目。

然而，当我们发现某个项目存在 Bug 时，通常的做法是提交 Issue 并静静地等待作者修复。

canal_bug_fix_01.png

实际上，更推荐的方式是 Fork 该项目，自行修复 Bug 并向项目提交 Pull Request（PR）。这不仅符合开源精神，还造福了所有使用该项目的人。

那么，如何实际参与 GitHub 上的开源项目呢？本文将以作者实际工作中的场景为例，详细介绍参与 GitHub 开源项目的步骤。

Canal Bug​

在工作中，我经常使用 MariaDB(11.2) 数据库，并使用 Canal 将 MariaDB 的增量数据变更同步到 Kafka。

canal_bug_fix_02.png

Canal 是阿里巴巴旗下的一款开源项目，使用 Java 开发，基于数据库增量日志解析，提供 MySQL 和 MariaDB 的增量数据订阅和消费。

在测试环境验证 Canal 订阅 MariaDB Binlog 的过程中，发现了一些报错：

canal_bug_fix_03.png

这些问题在生产环境是无法容忍的。幸运的是，在测试环境发现了这个问题，但如果只是向 Canal 官方提交 Issue等待修复，时间肯定不够。

所以，我们需要尝试自己修复这个 Bug。

我相信这样的场景多多少少每一位开发者都遇见过，我们享受了开源软件的便利，这个时候我们需要站出来奉献开源了[狗头]。

尝试修复​

通过查看相关的错误堆栈，找到了 Canal 上的关键代码：

canal_bug_fix_04.png canal_bug_fix_05.png

Canal 兼容解析 MariaDB 中的 Binlog 并没有 131 这个事件，所以导致解析 Binlog 报错了。

通过查看 MariaDB 官方 GitHub 项目，我们可以发现 Q_CHARCTER_SET_COLLATIONS 这个事件在 Buffer 中的操作。

canal_bug_fix_06.png

同时，我们也可以从 MariaDB 的 Binlog 解析中找到这个原始语句：

canal_bug_fix_07.png

修复 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 的流程：

  1. 将 Canal 项目克隆到自己的仓库 canal_bug_fix_08.png
  2. 修改代码后推送，在自己 Fork 的项目中点击 “New pull request” canal_bug_fix_09.png
  3. 选择自己的分支，以及要合并到 Canal 官方分支 canal_bug_fix_10.png
  4. 写必要的信息后，成功创建 PR，之后等待作者审核合并

总结​

GitHub是开发者接触最多的平台之一，最初我对 GitHub 并不理解，它不仅是一个代码仓库，还是无数开源软件社区的承载者。我们是社区中的受益者，也可以回馈社区。

以上就是我对于如何参与 GitHub 的思考和实际操作，希望这篇文章能够让您更好地理解和应用 GitHub。