Open edX定制开发与git rebase

#问题描述 折腾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版本上，只需要

git checkout wwj/course_category
git rebase product

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

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

git checkout product
git merge wwj/course_category

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

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

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

强大到令人叹为观止