使用Capistrano的Git工作流

我正在尝试使用capistrano了解一个好的git工作流。我找到了一个答案，但我要么没有完全理解他们的建议（可能），要么他们有点欠缺

到目前为止，我的想法是这样的，但我在何时合并回主分支（即，在转移到stage之前？之后？）并尝试将其连接到capistrano以进行部署时遇到了麻烦：

确保其他开发人员对远程主分支所做的所有更改都是最新的

• git签出主机

• git pull

创建一个新分支，该分支与您试图修复的特定bug相关

• git签出-b bug修复分支

做些改变

• git状态

• git添加。

• git commit-m“关于提交的友好消息”

所以，这通常是我被卡住的地方。此时，我有一个健康的主分支和一个新的bug修复分支，该分支包含我的（未测试的——单元测试除外）更改

如果我想将我的更改推送到stage（通过

cap staging deploy

），我是否必须将我的更改合并回master分支（我不希望这样做，因为看起来master应该没有未测试的代码）？我是否从master部署（或者我应该首先标记一个发布，然后修改我的

production.rb

文件以从该标记部署）？似乎解决了其中一些工作流问题，但我似乎无法了解它究竟是如何与cap暂存部署和cap生产部署挂钩的

想法？我假设有一种可能的规范方法可以做到这一点，但我要么找不到它，要么我对git来说太新了，以至于无法认识到我已经找到了它

---

救命啊

我这样做的方式是在你的回购协议上建立一个“分期”分支机构。您需要使用gem'capistrano ext'，它为stage提供了一些额外的配置选项（考虑到您在staging上部署的调用，我认为您已经在使用它了）

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的修复需要尽快反映在所有分支中，以便您的开发人员在相同的基础上工作。假设prod与staging有一个直接的共同祖先，而staging与master有一个共同祖先，那么应该根据prod分支的头向主题分支添加一个prod修复程序，然后将该更改与master合并，然后合并到staging中，最后部署到生产中。我们的想法是，唯一的区别是错误修复的提交，下次您将生产快进到登台的前端时，您已经有了表示您修复的产品错误的更改的对象，因此没有问题（因为有针对错误的良好测试，您知道它可以工作，在每个分支上运行套件之后）。否则，您可能必须从master中选择一个commit并应用于prod和staging。查看pro-git.org，了解更高级的工作流。

是的，我们肯定在使用capistrano ext（我无法想象回到过去）。我确实有一个关于这个设置的问题，比如说，当一个drop everything类型的bug出现在prod上时，你已经在准备进入prod的过程中从master到stage进行了一些更改。如果你从生产的最后一个标记创建了一个bug fix分支，那么你如何将其放到stage（以及随后的生产）上没有提到其他的更改？请参阅答案后面的注释。我一直关注到“最终部署到生产中”。如果你从prod HEAD创建一个分支，修复这个bug，合并到master中，然后进行staging——那么staging在那一点上会不会让你的新bug修复和其他已经被推到stage中的特性一起进行呢？如何从一个阶段合并到另一个产品，从而只升级bug修复代码？再次感谢您的帮助——我真的很感激。直接从主题分支申请。我将尝试添加一个psedo工作流，以显示我没有读过或看过那篇文章，但它听起来像是非常好的信息。图表是杀手级的，-no-ff标志是个好主意。