ruby-on-rails - 使用 Heroku 的分支策略进行良好的 Git 部署？

Question

与 Git + Heroku (Ruby on Rails) 一起使用的好的部署策略是什么？

目前，我使用原始 Git 存储库的方式是:所有功能(或“故事”)首先作为分支 check out ，然后与主库 merge 并推送到原始库。

任何推送到 origin/master 的东西都会触发一个脚本，将新的 Rails 代码 pull 到暂存区(简单的 Rails Web 服务器)。

当我需要将新的生产版本推送到 Heroku 时，我是否应该创建一个新分支(称为 production_version_121)，然后以某种方式将其推送到 Heroku？

理想情况下，我想从以前的开发版本中挑选出哪些特性我应该包含到生产分支中……测试它，然后推送到 Heroku。

例如，我可能不希望将所有最新代码都推送到生产环境中。我可能希望将我曾经开发过的功能“a”和功能“c”以某种方式 merge 到生产中，而不包括需要更多调试的实验功能“b”。

N.B.我将首先尝试避免使用 Capistrano，现在让一些东西手动工作。

有什么想法吗？最佳做法？

Answer 1

在 Gemcutter 项目中，我们只有一个 production 分支机构。我们希望在生产站点上看到的任何更改都将 merge 到该分支中，然后通过以下方式部署:

git push heroku production:master

staging 分支为暂存站点(也在 Heroku 上)提供类似的目的