我正试着用capistrano来解决一个好的git工作流程。我找到了few good articles，但我要么完全没有理解他们的建议（可能），要么他们有点缺乏。
这是我到目前为止的想法，但是当我合并回主分支时（即在移动到舞台之前？之后？）并尝试将其挂钩到capistrano进行部署时，我会陷入困境：
git checkout master git pull git checkout -b bug-fix-branch git status git add . git commit -m "Friendly message about the commit" 所以，这通常是我被卡住的地方。此时，我有一个健康的主分支和一个新的 bug-fix-branch ，它包含我的（未经测试的 - 除了单元测试）更改。
如果我想将我的更改推送到舞台（通过cap staging deploy），我是否必须将我的更改合并到主分支中（我不愿意，因为看起来主人应该保持免费未经测试的代码）？我是否甚至从master部署（或者我应该首先标记发行版，然后修改我的production.rb文件以从该标记部署）？ git-deployment似乎解决了其中一些工作流程问题，但我似乎无法弄清楚它究竟是如何实际挂钩到cap staging deploy和cap production deploy。
思考？我假设有一种可能的规范方式来做到这一点，但我不能找到它，或者我太新了，不能认识到我有< / em>找到了它。
帮助！
答案 0 :(得分：3)
我这样做的方法是在你的祝福仓库上设置一个'staging'分支。您将需要使用gem'capistrano-ext'，它为阶段提供了一些额外的配置选项（我认为您已经在考虑调用部署在暂存时使用此功能）。 capistrano-ext定义阶段，允许您为每个阶段创建一个部署文件，例如'staging'，您可以在其中定义要部署到的每个阶段唯一的分支set :branch, "staging"。您可以执行上述工作流程并添加：
#after commiting on bug-fix branch
git checkout staging # => tracks staging on origin
git merge bug-fix-branch # => bring new code in
git push origin staging # => capsitrano acts locally, it needs the code to get from origin
cap staging deploy # => wasnt that easy?
在一个理想的世界中，你也有一个生产分支，因此git分支会得到团队的同意
你有几种方法可以解决这个问题，我可以马上想到一个。对prod的修复需要尽快反映在所有分支中，以便你的开发人员在同一个基础上工作。假设prod有一个直接共同的祖先到分段，并且升级到掌握，应该根据prod分支的HEAD将主题分支添加到prod，然后将该更改与master合并，然后进入分段，最后部署到生产。这个想法是唯一的区别是bug修复的提交，下次你在staging上快速生产到头部时，你已经拥有了代表你修复的prod bug的变化的对象，所以没有问题（并且因为在每个分支上运行套件之后，对它知道它有效的错误进行了很好的测试）。否则你可能不得不从主人那里挑选一个提交并申请prod和staging。请查看pro-git.org以获取更高级的工作流程。