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

与Git + Heroku（Ruby on Rails）一起使用的优秀部署策略是什么？

目前我使用我的原始Git存储库的方式：所有function（或“故事”）首先作为分支检出，然后与master合并并推送到原点。

推送到origin / master的任何东西都会触发一个脚本，将新的rails代码拉到暂存区域（简单的rails webserver）。

当我需要将新的生产版本推送到Heroku时，我是否应该创建一个新的分支（称为类似于production_version_121），并以某种方式将其推送到Heroku？

理想情况下，我想选择我应该包含在生产分支中的先前开发版本中的哪些function…测试它，然后推送到Heroku。

例如，我可能不希望将所有最新代码推送到生产环境。 我可能想要我曾经使用的function“a”和function“c”都以某种方式合并到制作中，而不包括需要更多调试的实验性function“b”。

NB我首先要尝试避免使用capistrano并立即手动工作。

思考？ 最佳实践？

Answer 1

在Gemcutter项目中，我们只有一个生产分支。 我们希望在生产站点上看到的任何更改都合并到该分支中，然后部署：

git push heroku production:master 

staging分支为登台站点提供类似的用途（也在Heroku上）

Answer 2

自从我读过Vincent Driessen的一个成功的Git分支模型以来，我就被迷住了。 我的整个公司（我们8个）现在已经标准化了这个模型，我咨询过的其他一些地方也开始使用它。

我所展示的大多数人都表示他们已经做了类似的事情并且发现很容易适应。

简而言之，您有2个永久性分支（主要和开发）。 大多数时候，你只是在制定分支并将它们合并回发展中。 当你开始进行生产发布和修补程序时，事情会变得复杂一些，但是在阅读了几次post之后，它就会变得僵硬。

甚至还有一个名为git-flow的命令行工具来帮助你。

Answer 3

有很多方法可以解决这个问题，这取决于你的偏好。

我会给你一个可能的策略：鉴于你已经有一个使用master的自动分段设置，我建议你创建一个’production’分支。 如果要将修订/function提升为生产，只需将主题分支合并到“生产”分支中即可。

 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 tag ，并使用git show release-1234查看它们。 有关标记的更多信息，请运行git help tag 。 您可能还会发现有关标记的Github指南很有帮助。 我还建议阅读其他人的工作流程（这是一篇很好的文章 ）并挑选适合你的方法。