合并Spark社区代码的正确姿式

时间 2019-11-06

标签合并 spark 社区代码正确栏目 Spark 繁體版

原文原文链接

原创文章，转载请保留出处html

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

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

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

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

准备Spark代码

通常来讲，本身维护一套Spark代码，须要Fork下社区项目，在clone本身Fork的代码，进行开发。我这里以Spark 2.2.0为例。post

clone本身Fork的仓库到本地性能

# stanzhai是个人GitHub帐号，你们须要换成本身的仓库地址
git clone https://github.com/stanzhai/spark.git
cd spark

添加一个名为upstream的远程仓库指向社区的版本库测试
```
git remote add upstream https://github.com/apache/spark.git
```

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

[remote "upstream"]
    url = https://github.com/apache/spark.git
    fetch = +refs/heads/*:refs/remotes/upstream/*
    fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*  # 注意添加这行

同步远端库，更新分支引用（每次合并前都须要执行）大数据
```
git remote update
```
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

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

➜  spark git:(my-2.2.0) ✗ git cherry-pick 2c5b9b1173c23f6ca8890817a9a35dc7557b0776
[my-2.2.0 529f5ea55ff] [SPARK-22083][CORE] Release locks in MemoryStore.evictBlocksToFreeSpace
 Author: Imran Rashid <irashid@cloudera.com>
 Date: Mon Sep 25 12:02:30 2017 -0700
 2 files changed, 153 insertions(+), 13 deletions(-)

若是合并的代码刚好也被你改过了，那么有可能会出现冲突，这种状况正常解决冲突，而后git commit就能够了。

整合还没有合并到社区的PR

因为一个PR可能包含屡次提交，整合未合并到社区的PR就比较麻烦了。Spark的主干代码天天都有变更，直接对比两个不一样的分支变更一般会比较大，咱们须要将PR中n次提交的代码的全部变动梳理出来，而后在作整合。

咱们以这个PR为例：https://github.com/apache/spark/pull/19301，这个PR实现上还有待改进，但能够正常工做，所以还没合入社区，咱们将这个PR合并到my-2.2.0分支，须要进行如下操做：

# 更新远程仓库及版本引用信息
git remote update

# 基于某个PR建立一个分支，这里的19301是这个PR在GitHub上的id
git checkout -b pr-19301 upstream/pr/19301
git checkout pr-19301

# PR分支大都基于master开发，以upstream/master分支为基准，从新apply PR分支上的修改
git rebase upstream/master

# 经过diff提取此次PR的patch文件
git diff upstream/master > pr-19301.patch

# 到目标分支打patch
git checkout my-2.2.0
git apply --reject pr-19301.patch

# 查看上一步apply的状态
git status
# apply有可能会不成功，还没有apply的patch被存放到*.rej文件中，须要手动处理，最后提交便可
git commit -a

# 清理
rm pr-19301.patch
rm *.rej
git branch -D pr-19301

参考

最后

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

文章首发自知乎专栏：Spark大数据技术，专一大数据、Spark相关技术，欢迎关注。

听说看完这篇文章给个赞的同窗，打Patch都不会遇到冲突 ~(≧▽≦)/~