在Heroku中使用分支策略的良好Git部署？
用于Git + Heroku（Ruby on Rails）的良好部署策略是什么？
目前，我使用我的起源Git存储库的方式：所有功能（或'故事'）首先作为分支签出，然后与主合并并推送到原点。
任何推送到origin / master的东西都会触发一个脚本，将新的rails代码拖到暂存区（简单的rails webserver）。
当我需要将一个新的生产版本推送到Heroku时，我是否应该创建一个新分支（称为类似production_version_121的东西），并将其推向Heroku？
理想情况下，我想选择我应该包含到生产分支中的以前开发版本中的哪些功能...测试它，然后推送到Heroku。
例如，我可能不希望所有最新的代码被推到生产中。 我可能想要功能“a”，我已经工作，功能“c”都以某种方式合并到生产中，而不包括需要更多调试的实验功能“b”。
注意我首先尝试避开卡皮斯特拉诺，然后为手动获取某些东西。
思考？ 最佳实践？
在Gemcutter项目中，我们只有一个生产分支。 我们希望在生产站点上看到的任何更改都会合并到该分支中，然后通过以下方式进行部署：
git push heroku production:master
staging分支为临时站点提供类似的目的（也在Heroku上）
自从我读过文森特Driessen的一个成功的Git分支模型以来，我一直都很迷惑。 我的整个公司（我们中的8个）现在已经在这个模型上进行了标准化，并且我咨询过的其他一些地方也开始使用它。
我向大家展示的大多数人都表示，他们已经在做类似的事情，并发现很容易适应。
简而言之，你有两个永久的分支（主和开发）。 大多数情况下，你只需要开发分支并将其合并为开发。 当你进行产品发布和修补程序时，事情会变得更复杂一些，但在阅读了这篇文章几次之后，它就会变得沉静下来。
甚至有一个叫做git-flow的命令行工具可以帮助你。
有很多方法可以解决这个问题，这取决于你的偏好。
我会给你一个可能的策略：假设你已经有了一个使用master的自动化登台设置，我会建议创建一个'production'分支。 如果要将修补程序/功能提升为生产，只需将主题分支合并到“生产”分支中即可。
git checkout production
git pull . my-topic-branch
(resolve any conflicts)
当您准备将代码实际推送到生产服务器时，您应该使用唯一名称（可能带有时间戳）来标记分支。 然后，您只需将制作分支推送到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指南。 我还建议阅读其他人的工作流程（这里有一个很好的文章），然后挑选适合自己的工作流程。
上一篇: Good Git deployment using branches strategy with Heroku?