与 Git + Heroku（Ruby on Rails）一起使用的好的部署策略是什么？
目前，我使用原始 Git 存储库的方式：首先将所有功能（或“故事”）作为分支检出，然后与 master 合并并推送到原始存储库。
任何推送到 origin/master 的东西都会触发一个脚本，将新的 rails 代码拉到暂存区域（简单的 rails 网络服务器）。
当我需要将新的生产版本推送到 Heroku 时，我是否应该创建一个新分支（称为 production_version_121 之类的东西），然后以某种方式将其推送到 Heroku？
理想情况下，我想从以前的开发版本中挑选哪些功能应该包含到生产分支中……测试它，然后推送到 Heroku。
例如，我可能不希望所有最新代码都被推送到生产环境。我可能想将我曾经研究过的“a”和“c”都以某种方式合并到生产中，而不包括需要更多调试的实验性“b”。
请注意，我将首先尝试避免 Capistrano 并暂时手动进行一些工作。
有什么想法吗？最佳实践？
In the Gemcutter project we simply have a production branch. Any changes that we want to see on the production site get merged into that branch, and then deployed with:
git push heroku production:master
The staging branch serves a similar purpose for the staging site (also on Heroku)
Ever since I read Vincent Driessen's A successful Git branching model, I have been hooked. My entire company (8 of us) have now standardized on this model and a few other places I've consulted with have also started using it as well.
Most everyone I've shown it to says they were doing something similar already and found it very easy to adapt.
In a nutshell, you have 2 branches that are permanent (master and develop). Most of the time you'll just be making branches off of develop and merging them back into develop. Things get a little more complex when you get into doing production releases and hotfixes, but after reading the post a couple of times, it becomes engrained.
There's even a command line tool called git-flow to help you out.
有多种方法可以解决此问题，这实际上取决于您的偏好。
我会给你一个可能的策略：鉴于你已经有一个使用 master 的自动登台设置，我建议创建一个“生产”分支。当您想将修复/功能提升到生产时，您只需将主题分支合并到您的“生产”分支中。
git checkout production
git pull . my-topic-branch
(resolve any conflicts)
When you are ready to actually push that code to your production server, you should tag the branch using a unique name (probably with a timestamp). Then you simply push the production branch to Heroku.
git checkout production
git tag release-200910201249
I'd suggest creating a script or git alias to automate the tagging for timestamps, since using a consistent naming scheme is important. I use something like this:
git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`'
That allows me to do just type git dtag when I want to tag a release with a timestamp.
You can view you tags using git tag and view them using git show release-1234. For more information on tags, run git help tag. You may also find this Github guide on tagging helpful. I'd also recommend reading up other people's workflows (here's a nice writeup) and pick and choose what works for you.