如何高效地合并Spark社区PR到自己维护的分支

更多腾讯海量技术文章，请关注云加社区：https://cloud.tencent.com/developer/column

作者：挖掘大数据

最近刚刚忙完Spark 2.2.0的性能测试及Bug修复，社区又要发布2.1.2了，国庆期间刚好有空，过了一遍2.1.2的相关JIRA，发现有不少重要修复2.2.0也能用上，接下来需要将有用的PR合到我们内部维护的2.2.0分支上了。

经常有朋友问我是怎么把社区的PR合到自己分支上的，我之前跟他们介绍的做法是基于PR拉分支，在IDEA中单个文件diff合并。如果是偶尔合下社区代码，这种方式也不算太费事。但是如果PR中改动的文件较多，或者要合并多个PR过来，这种方式也挺麻烦。

废话到此，这篇文章是介绍，如何高效地合并Spark社区PR到自己维护的分支(常说的打Patch)，当然，针对其他开源项目，该方法同样适用。

PR：Pull Request是GitHub上的一个功能，开源代码的贡献者，通过发起一个Pull Request向社区贡献代码。

准备Spark代码

一般来说，自己维护一套Spark代码，需要Fork下社区项目，在clone自己Fork的代码，进行开发。我这里以Spark 2.2.0为例。

1、 clone自己Fork的仓库到本地

# stanzhai是我的GitHub账号，大家需要换成自己的仓库地址

git clone https://github.com/stanzhai/spark.git

cd spark

2、 添加一个名为upstream的远程仓库指向社区的版本库

git remote add upstream https://github.com/apache/spark.git

3、 设置PR引用，编辑git配置vi .git/config，找到upstream，添加最后一行fetch

[remote "upstream"]

url = https://github.com/apache/spark.git

fetch = +refs/heads/*:refs/remotes/upstream/*

fetch = +refs/pull/*/head:refs/remotes/upstream/pr/* # 注意添加这行

4、 同步远端库，更新分支引用（每次合并前都需要执行）

git remote update

5、 checkout一个2.2.0的维护分支

git checkout -b my-2.2.0 v2.2.0

我们创建了一个基于2.2.0的my-2.2.0分支，下面的示例是将社区PR合并到my-2.2.0分支中。

提交给社区的PR大致分为2类：

PR被接受，且被合并到社区的仓库

PR没有合并到社区仓库，(代码没问题，有可能commiter还没来得及处理)

整合已被社区合并的PR

被合并到社区的PR已经做了rebase处理，对于这种PR，合并到自己的分支中是非常简单的事情，直接使用git的cherry-pick就可以搞定。

我们以这个卡片为例：https://issues.apache.org/jira/browse/SPARK-22083

这个卡片被标记为resolved，而且PR也被合到社区仓库了：https://github.com/apache/spark/pull/19311，我们打开这个链接，到页面下方，找到这个位置：

打开后，会跳转到这个地址：https://github.com/apache/spark/commit/2c5b9b1173c23f6ca8890817a9a35dc7557b0776，地址中后面的一长串就是我们需要的commit-id，得到这个就可以直接合并代码了：

git remote update

git cherry-pick 2c5b9b1173c23f6ca8890817a9a35dc7557b0776

执行完，提示以下信息就表示合并成功了：

如果合并的代码恰好也被你改过了，那么有可能会出现冲突，这种情况正常解决冲突，然后git commit就可以了。

整合尚未合并到社区的PR

由于一个PR可能包含多次提交，整合未合并到社区的PR就比较麻烦了。Spark的主干代码每天都有变动，直接对比两个不同的分支变动通常会比较大，我们需要将PR中n次提交的代码的所有变更梳理出来，然后在做整合。

我们以这个PR为例：https://github.com/apache/spark/pull/19301，这个PR实现上还有待改进，但可以正常工作，因此还没合入社区，我们将这个PR合并到my-2.2.0分支，需要进行以下操作：

参考

Useful Developer Tools

A successful Git branching model

Git 分支 - 分支的衍合

最后

上述方法不能保证合并PR 100%成功，原则上你的分支和社区代码越近，冲突越少，越容易处理。Spark 2.x的代码有很大的变动，把针对2.x的PR打到1.6的分支上，往往是个麻烦事。