#问题描述 折腾Open edX的过程中,我们得做许多自己的定制。

将定制内容封装成xblock或django app是最好不过,迁移起来是方便的。可如果不得不侵入源码,诸如修改模板之类(这类事总会遇到)。那么如何在迁移edx的版本的过程中,同步自己定制的内容,是个很让人头疼的问题

#思路 这个问题我能想到的最佳方案是使用模块化的思路版本管理系统

关于模块化的思路,我在edX开发相关里总结过,不妨搬过来:

  • 把代码尽量的模块化,定制的功能,可以的话,尽量整个丢到django app里
  • 尽量不要去入侵edx-platform源代码,尽可能采用非侵入式插件风格的定制 诸如主题的定制,你应当使用theme,而不是去改templates
  • 诸如要课程分类,添加属性,尽量不要去动课程模型,而是自建model,采用course_id关联到原有课程。而后整个功能模块丢到django app里。

至于如何利用版本管理系统来方便我们进行版本变迁,此前并没细说,在此总结下

#git层面的视角 让我们从git层面来看看我们面临的是怎样的问题

我们首先fork了edx/edx-platform,于是我们有了一个自己的副本(远程仓库),对此有读写权限,在开发环境中,把它clone到本地,checkout出当前最新的稳定版named-release/cypress.rc,在此之上建立自己的开发分支,就可以开发我们想要的功能了,如果是团队协作,那么一般以{yourname}/{feature}命名分支,开发完成后,由负责人将新功能merge到生产分支(product)上

至此问题都不大,小伙伴们其乐融融,齐头并进

忽然有一天edX宣布说Dogwood版本正式发布,大家期待多时的数据分析功能也可本地使用了。那么多数人都会想升级版本。

此后才发现,我们都有了许多历史负担,我们有了太多的个性化定制。如果最初没有对定制内容进行管理,那么下面就没你啥事啦,升级的痛苦会让你不愿尝试,尤其是升级从来就不只这一次

如果你在前头有基于分支来开发定制,那么你只要用好git rebase就可以无痛迁移啦,定制升级两不误!

#git rebase 在edx/edx-platform的wiki中,官方就有给大家打好预防针了,提醒大家以git rebase的方式来平滑迁移迁移内容:How to Rebase a Pull Request

不过这显然不是一篇优秀的介绍文档,关于git rebase,更好的资料是Git 分支 - 变基

##关于git rebase 当很多人同时在一个工程上工作的时候,一个拉取请求很快就会过时。一个过时的拉取请求就是一个不再和开发主线保持同步的开发分支,它在合并到工程里面之前需要被更新.

如果你的拉取请求已经过时了,在你的分支能被合并之前,你需要将你的分支变基到主分支最新版本。

这个时候你就需要git rebase的帮助了

一般来说git rebase就是在以上场合中被使用。

##开始升级

同样的道理,我们也可以git rebase用于将开发分支迁移到不同的提交上(Dogwood/Cypress本质上仅仅是个tag而已,指向某次提交)。

好比我们要将基于Cypress的wwj/course_category分支迁移到Dogwood版本上,只需要

1
2
git checkout wwj/course_category
git rebase product

过程中,可能要处理一些冲突,就像git merge中那样

其中product是基于named-release/dogwood.rc,现在切换回product,进行一次快进合并

1
2
git checkout product
git merge wwj/course_category

同样的道理,其他特性分支也一并这样做,完成后,升级工作就完成啦!
更爽在于,即便之后edX又发布了新版本,我们依然能够按照以上步骤无痛迁移!

如果了解一些远程分支相关的知识,这部分会更融通

不得不承认,git几乎成为了源码管理/协作开发/升级部署的核心

强大到令人叹为观止

#资料 * How to Rebase a Pull Request * Git 分支 - 变基