这篇文章听起来很有趣，但我很确定图表是错误的。 http://guides.beanstalkapp.com/version-control/branching-best-practices.html
不应该是DEVELOPMENT＆gt; STAGING＆gt; PRODUCTION？
合并应该只朝一个方向流动：从功能和错误修复 在他们自己的分支或开发中进行测试。 经过测试，您可以将这些更改从开发合并到 生产
这里我有点困惑。所以我将Staging与Master或Master合并到Staging？
我正在使用一个名为SmartGit的客户端，我对这一点感到困惑。通常我为一个功能创建一个分支，提交它，然后切换到master并将其合并到分支（forward）。因此，在这个带有Staging and Production的新工作流程中，我创建了这两个额外的分支，然后从master（aka dev）为我的功能创建一个分支。提交它，然后切换到暂存并合并（转发）到我的功能分支？这听起来不错吗？
实际上让人如此困惑的是，Beanstalk人员支持非常非标准地使用Staging（它在他们的图表中开发之前，并不是一个错误！ https://twitter.com/Beanstalkapp/status/306129447885631488
决定忘记Beanstalk和Github。
自从我发布此消息后，Beanstalk人员接受了我的提示并重命名了他们的阶段，现在称为开发“稳定”。
答案 0 :(得分：67)
这里的思考过程是您将大部分时间花在development上。在开发过程中，您创建一个feature分支（从development开始），完成该功能，然后合并回development。然后可以通过合并到production将其添加到最终生产版本中。
有关此方法的详细信息，请参阅A Successful Git Branching Model。
答案 1 :(得分：5)
我们采用不同的方式。恕我直言，我们以更简单的方式做到：在master我们正在研究下一个主要版本。
每个较大的特征都有自己的分支（从master获得），并且将由开发人员定期在master之上进行重新定位（+强制推送）。只有单个开发人员使用此功能时，重新绑定才能正常工作。如果该功能完成，它将被重新安装到主设备上，然后主设备快速转发到最新的功能提交。
为了避免重新定位/强制推送，还可以定期将主更改合并到功能分支，如果已完成将功能分支合并到主设备（正常合并或压缩合并）。但恕我直言，这使得功能分支不太清晰，并且使重新排序/清理提交变得更加困难。
如果要发布新版本，我们会创建一个主分支，例如release-5只有错误得到修复。
答案 2 :(得分：3)
实际上是什么让这个让人感到困惑的是，Beanstalk人员支持他们非常非标准地使用Staging（它在他们的图表中开发之前就出现了，这不是一个错误！
答案 3 :(得分：1)
关于git的最好的事情之一就是你可以改变最适合你的工作流程。我大部分时间都使用http://nvie.com/posts/a-successful-git-branching-model/但你可以使用任何符合你需求的工作流程