斯坦福运行一个工程师团队积极开发的 OpenEdX 代码库实例。 我们在 github.com/Stanford-Online/edx-platform 我们尝试通过每月从 edX 的主要 edx 平台存储库中合并来使我们的 fork 接近 edX master（github.com/edx/edx-平台）。 我们更喜欢通过拉取请求 (PR) 将代码登陆到 edX 的主存储库，但有时这是不可能的，因为我们会定期构建自定义的斯坦福特定功能。 通过迭代，我们采用了明确定义的发布流程，该流程适应从主 edX 存储库合并和保持我们自己独立的工作流 主 分支。 由于我们正在运营一个拥有大量用户的网站，因此我们认为发布的稳定性至关重要。 这意味着我们会非常努力地将不良代码排除在外。 释放 分支，并且发布过程促进了这一点。
当我们向 edX 和我们自己提交 PR 时，我们需要从我们的开发环境中访问 edX 的存储库，因此斯坦福的大多数开发人员运行 git 环境时至少有两个遥控器（有时更多的是个人遥控器和同事）： 起源，斯坦福代码库； 和 上游，edX 代码存储库，我们可以从中签出 master 分支以对 edX 进行 PR。 我们也用这个 上游 在我们的发布过程中远程合并来自 edX 的代码更改。
这就是我看到需要解释发布过程的图表的地方。 我是一个视觉的人，画出一些东西是我理解事物的方式。 这是我的图表，以帮助描述我们的开发和发布工作流程：
它特别有用，因为我们的开发人员轮流负责我们轮换的“发布大师”系统中的发布。 该图使我们的发布周期在发布之间保持一致并最大限度地减少错误。
以下是使用图表作为指南的发布计划：
1.首先我们创建一个 rc 从我们的 master 分支分支出来，接受任何已合并到的开发 主 自上次发布以来。
1a。 如果我们想合并 上游 释放 分支到 rc 分支，我们在这里做。
在这一点上，我们有一个可以测试的候选版本，一旦我们确信它不会破坏任何东西，然后安装到我们的生产机器上.
2. 现在我们合并分支 rc 进入分支 释放 （这应该是一个简单的快进；如果不是，则以前的版本有问题！）。
3.现在 释放 分支（和合并的 上游 代码）可以合并回 主 分支以保持两个分支彼此同步。
请注意，功能分支是从 主 并重新合并以在常规发布周期中发布。 另一方面，修补程序是分支的 释放, 合并回 释放，立即推送到生产环境，然后合并回 主 保持同步。 还要注意 释放 变化和 上游 合并不成 主 除非它们在测试后被认为是安全的，否则它们是绝缘的 主 也来自错误。
就是这样！ 我们为我们维护的每个分叉存储库使用这种分支模型，这使所有内容保持一致和可预测。
