与Git + Heroku（Ruby on Rails）一起使用的优秀部署策略是什么？
目前我使用我的原始Git存储库的方式：所有功能（或“故事”）首先作为分支检出，然后与master合并并推送到原点。
任何推送到origin / master的东西都会触发一个脚本，将新的rails代码拉到临时区域（简单的rails webserver）。
当我需要将新的生产版本推送到Heroku时，我应该创建一个新的分支（称为类似于production_version_121），并以某种方式将其推送到Heroku吗？
理想情况下，我想选择我应该包含在生产分支中的先前开发版本中的哪些功能...测试它，并推送到Heroku。
例如，我可能不希望将所有最新代码推送到生产环境。我可能想要一个我曾经工作过的功能“a”并且功能“c”都以某种方式合并到制作中，而不包括需要更多调试的实验性功能“b”。
N.B。我将首先尝试避免使用capistrano并暂时手动工作。
思考？最佳实践？
答案 0 :(得分：32)
在Gemcutter项目中，我们只有一个 production 分支。我们希望在生产站点上看到的任何更改都会合并到该分支中，然后使用以下部署进行部署：
git push heroku production:master
staging分支与暂存站点（也在Heroku上）具有相似的用途
答案 1 :(得分：16)
自从我读过Vincent Driessen的A successful Git branching model以来，我就被迷住了。我的整个公司（我们8个人）现在已经标准化了这个模型，我咨询过的其他几个地方也开始使用它。
我所展示的大多数人都表示他们已经做了类似的事情并且发现很容易适应。
简而言之，你有两个永久性的分支（掌握和开发）。大多数情况下，你只是在开发分支并将它们合并回开发。当你进入生产版本和修补程序时，事情会变得复杂一些，但是在阅读了几篇文章之后，它就会变得黯然失色。
甚至还有一个名为git-flow的命令行工具可以帮助你。
答案 2 :(得分：7)
有很多方法可以解决这个问题，这实际上取决于您的偏好。
我将为您提供一个可能的策略：鉴于您已经拥有使用master的自动分段设置，我建议您创建一个“生产”分支。如果要将修订/功能提升为生产，只需将主题分支合并到“生产”分支中即可。
git checkout production
git pull . my-topic-branch
(resolve any conflicts)
当您准备将该代码推送到生产服务器时，您应该使用唯一名称tag分支（可能带有时间戳）。然后你只需将生产分支推送到Heroku。
git checkout production
git tag release-200910201249
我建议创建一个脚本或git别名来自动标记时间戳，因为使用一致的命名方案很重要。我使用这样的东西：
git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`'
当我想用时间戳标记发布时，这允许我只键入git dtag。
您可以使用git tag查看标记，并使用git show release-1234查看标记。有关标记的更多信息，请运行git help tag。您还可以在标记上找到此Github guide。我还建议阅读其他人的工作流程（这里是a nice writeup）并挑选适合您的工作流程。