我正在尝试使用 capistrano 来了解一个良好的 git 工作流程。我找到了一个few http://nakedstartup.com/2010/04/simple-daily-git-workflow/ good http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html articles http://www.reasonablyopinionated.com/2009/09/git-deployment-workflow-and-capistrano.html，但我要么没有完全理解他们的建议（可能），要么他们有些缺乏。
到目前为止，我的想法是这样的，但是我在何时合并回主分支（即在转移到阶段之前？之后？）并尝试将其挂接到 capistrano 进行部署时遇到了问题：
- Make sure you’re up to date with all the changes made on the remote master branch by other developers
git checkout mastergit pull
- Create a new branch that pertains to the particular bug you're trying to fix
git checkout -b bug-fix-branch
- Make your changes
git statusgit add .git commit -m "Friendly message about the commit"
所以，这通常是我陷入困境的地方。此时，我有一个master健康且新的分支错误修复分支其中包含我的（未经测试的——单元测试除外）的更改。
如果我想将我的更改推向阶段（通过cap staging deploy），我是否必须将我的更改合并回 master 分支（我不想这样做，因为 master 似乎应该保留未经测试的代码）？我是否应该从 master 进行部署（或者我应该先标记一个版本，然后修改我的production.rb要从该标签部署的文件）？git 部署 https://github.com/apinstein/git-deployment/似乎解决了其中一些工作流程问题，但我似乎无法找出它实际上如何挂钩到上限部署和上限生产部署。
想法？我认为有可能典范这样做的方法，但我要么can't找到它，或者我对 git 太陌生，无法认识到我have找到了。
Help!
我这样做的方法是有一个“暂存”分支，可以在您的仓库上进行跟踪。您将需要使用 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 分支被团队商定为
- 高手-边缘代码所在团队
开发者之间的共享
- staging - 待测试的代码
临时服务器上的客户端
（主合并快进）
- 生产-稳定发布
（从舞台快进）
编辑：对评论的回复太长，所以我不得不附加到答案。
你有几种方法可以解决这个问题，我马上就能想到一种。对产品的修复需要尽快反映在所有分支中，以便您的开发人员在同一基础上工作。假设 prod 与 staging 有直接的共同祖先，并且 staging 到 master，则应将 prod 的修复添加到基于 prod 分支的 HEAD 的主题分支，然后将该更改与 master 合并，然后合并到 staging 中，最后部署到生产。这个想法是，唯一的差异是错误修复的提交，下次您将生产快进到暂存的头部时，您已经拥有了代表您修复的产品错误的更改的对象，因此没有问题（并且由于对错误进行了良好的测试，因此在每个分支上运行该套件后，您知道它是有效的）。否则，您可能必须从 master 中挑选一个提交并应用于 prod 和 staging。请访问 pro-git.org 了解类似的更高级的工作流程。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
