84

这篇文章听起来很有趣，但我很确定图表是错误的。 http://guides.beanstalkapp.com/version-control/branching-best-practices.html

不应该是DEVELOPMENT> STAGING>PRODUCTION吗？

合并应该只流向一个方向：从在自己的分支或开发中完成的功能和错误修复到测试阶段。测试后，您可以将这些更改从开发合并到生产中。

在这里我有点困惑。所以我将 Staging 合并到 Master 或 Master 到 Staging？

我正在使用一个名为 SmartGit 的客户端，我对这一点感到困惑。通常我为一个特性创建一个分支，提交它，然后切换到 master 并将其合并到分支（转发）。因此，在这个包含 Staging 和 Production 的新工作流程中，我创建了这两个额外的分支，然后从 master（又名 dev）为我的功能创建一个分支。提交它，然后切换到暂存并合并（转发）到我的功能分支？这听起来正确吗？

实际上让这件事如此令人困惑的是 Beanstalk 人支持他们非常不标准地使用 Staging（在他们的图表中它出现在开发之前，这不是一个错误！ https://twitter.com/Beanstalkapp/status/306129447885631488

已经决定忘记 Beanstalk，直接使用 Github。

自从我发布了这篇文章后，Beanstalk 的人接受了我的提示，并重新命名了他们的阶段，现在将 Development 称为“Stable”。

4

4 回答 4

103

这里的思考过程是您将大部分时间花在development. 在开发中，您创建一个feature分支（关闭development），完成功能，然后合并回development. 然后可以通过合并将其添加到最终生产版本中production。

有关此方法的更多详细信息，请参阅成功的 Git 分支模型。

于 2013-02-25T17:02:59.250 回答
5

我们做的不同。恕我直言，我们以更简单的方式做到这一点：master我们正在开发下一个主要版本。

每个较大的功能都有自己的分支（从 master 派生），并且将由开发人员定期在 master 之上重新定位（+强制推送）。仅当单个开发人员使用此功能时，重新定基才能正常工作。如果功能完成，它将重新基于主节点，然后主节点快速转发到最新的功能提交。

为了避免变基/强制推送，还可以定期将主更改合并到功能分支，如果完成，将功能分支合并到主分支（正常合并或壁球合并）。但是恕我直言，这使功能分支变得不那么清晰，并使重新排序/清理提交变得更加困难。

如果新版本即将发布，我们会在 master 之外创建一个侧分支，例如release-5只修复错误。

于 2013-02-25T20:16:17.160 回答
3

实际上，让这变得如此混乱的是 Beanstalk 人支持他们非常不标准地使用 Staging（在他们的图表中它出现在开发之前，这不是一个错误！

https://twitter.com/Beanstalkapp/status/306129447885631488

于 2013-03-13T19:12:16.390 回答
2

关于 git 最好的事情之一是您可以更改最适合您的工作流程.. 我大部分时间都使用http://nvie.com/posts/a-successful-git-branching-model/但是您可以使用任何适合您需求的工作流程

于 2013-02-28T23:50:47.830 回答