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

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

最近刚刚忙完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过来,这种方式也挺麻烦。

[[206086]]

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

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

准备Spark代码

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

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

 

  1. # stanzhai是我的GitHub账号,大家需要换成自己的仓库地址  
  2. git clone https://github.com/stanzhai/spark.git  
  3. cd spark 

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

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

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

 

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

4、 同步远端库,更新分支引用(每次合并前都需要执行)

  1. git remote update 

5、 checkout一个2.2.0的维护分支

  1. 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,我们打开这个链接,到页面下方,找到这个位置:

 

[[206087]]

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

 

  1. git remote update  
  2. git cherry-pick 2c5b9b1173c23f6ca8890817a9a35dc7557b0776 

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

 

  1. ➜ spark git:(my-2.2.0) ✗ git cherry-pick 2c5b9b1173c23f6ca8890817a9a35dc7557b0776 
  2. [my-2.2.0 529f5ea55ff] [SPARK-22083][CORE] Release locks in MemoryStore.evictBlocksToFreeSpace 
  3. Author: Imran Rashid 
  4. Date: Mon Sep 25 12:02:30 2017 -0700 
  5. 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分支,需要进行以下操作:

 

  1. # 更新远程仓库及版本引用信息 
  2. git remote update 
  3.  
  4. # 基于某个PR创建一个分支,这里的19301是这个PR在GitHub上的id 
  5. git checkout -b pr-19301 upstream/pr/19301 
  6. git checkout pr-19301 
  7.  
  8. # PR分支大都基于master开发,以upstream/master分支为基准,重新apply PR分支上的修改 
  9. git rebase upstream/master 
  10.  
  11. # 通过diff提取这次PR的patch文件 
  12. git diff upstream/master > pr-19301.patch 
  13.  
  14. # 到目标分支打patch 
  15. git checkout my-2.2.0 
  16. git apply --reject pr-19301.patch 
  17.  
  18. # 查看上一步apply的状态 
  19. git status 
  20.  
  21. # apply有可能会不成功,尚未apply的patch被存放到*.rej文件中,需要手动处理,最后提交即可 
  22. git commit -a 
  23.  
  24. # 清理 
  25. rm pr-19301.patch 
  26. rm *.rej 
  27. git branch -D pr-19301 

参考

Useful Developer Tools

A successful Git branching model

Git 分支 - 分支的衍合

最后

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

责任编辑:未丽燕 来源: 知乎
相关推荐

2018-01-11 15:31:39

命令Linux关机

2017-02-23 15:37:44

OptionObject容器

2016-05-09 10:41:03

算法分析开发

2017-03-16 11:39:33

Openstack源码姿势

2017-07-10 13:09:45

前端Flexbox

2023-01-30 07:41:43

2021-01-08 08:10:34

MySQL表空间回收

2019-12-27 15:58:57

大数据IT互联网

2016-12-12 08:48:24

2024-09-25 08:22:06

2021-09-15 16:20:02

Spring BootFilterJava

2019-10-30 17:06:50

AWS物联网IoT

2017-12-12 16:43:54

SparkHadoop水平

2020-02-24 15:26:40

Python短信免费

2016-01-05 11:28:20

按需付费云计算docker

2017-06-19 17:43:04

网络带宽网络设计

2022-03-28 11:10:35

ShellBash forLinux

2019-01-02 10:49:54

Tomcat内存HotSpot VM

2018-06-13 10:27:04

服务器性能优化

2015-07-13 11:32:09

PHP程序员正确姿势
点赞
收藏

51CTO技术栈公众号