带有开发、暂存和生产分支的 git答案

【问题标题】：git with development, staging and production branches带有开发、暂存和生产分支的 git
【发布时间】：2013-02-25 17:00:17
【问题描述】：

这篇文章听起来很有趣，但我很确定图表是错误的。 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 人员接受了我的提示，并重新命名了他们的阶段，现在将开发称为“稳定”。

【问题讨论】：

您可能希望将修复从登台合并到生产。为了测试而合并到暂存，然后在测试完成时将开发合并到生产中，这为开发的额外工作合并到从未合并到暂存的生产提供了可能性。
经典分支工作流并不容易应用于 Git，因为 Git 中的分支要轻量级得多。它们只是指向历史中（单个）提交的指针，历史本身可以向多个方向分支。这就是为什么很难将分支视为分离开发的“线”（这也适用于“成功的 Git 分支模型”中的图表）。
是的，它不完全是泳道。但我的问题更具体：我是切换到 Staging 并合并到 dev，还是反之亦然？我是 git 新手，对此感到困惑。也许我应该直接向我的 windows git 客户端 SmartGit 的制造商提出这个问题。
我一直在寻找的一个确切问题。搜索谷歌并在第一个号码上得到了这个。耶（y）

标签： git

【解决方案1】：

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

有关此方法的更多详细信息，请参阅A Successful Git Branching Model。

【讨论】：

+1 表示“成功的 Git 分支模型”。就 git 工作流程而言，这基本上已成为标准。
“一个成功的 Git 分支模型”对于参与人数很少的小型项目来说有点复杂。我更喜欢更简单的方法，在 master 分支中进行开发，在 master 分支中标记稳定版本，如果需要，它们具有用于补丁的稳定分支。见stackoverflow.com/questions/14858075/… 和scottchacon.com/2011/08/31/github-flow.html
谢谢@JosefKufner github 流文章很有帮助
@eykanal 你是否将development 合并到production 或feature 到production 中？
本文中没有暂存分支。他们如何从开发服务器部署到登台？我只看到他们如何直接从 dev 部署到生产 - 将 dev 分支合并到 master，但这并不安全，因为它跳过了暂存环境，不是吗？

【解决方案2】：

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

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

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

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

【讨论】：

我不知道这意味着什么。
有什么不明白的地方？

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

关于 git 的一大优点是您可以更改最适合您的工作流程。我确实大部分时间使用http://nvie.com/posts/a-successful-git-branching-model/，但您可以使用任何适合您需要的工作流程

【讨论】：