具有开发、分期和生产分支的git

这篇文章听起来很有趣，但我很确定图表是错的。

它不应该是

开发

登台

生产

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

在这里我有点困惑。所以我把暂存合并到主暂存还是主暂存

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

---

---

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

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

---

---

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

这里的思想过程是你将大部分时间花在

开发上。在开发中，你创建了一个
功能
分支（从
开发
），完成该功能，然后合并回
开发
。然后可以通过合并到
生产
将其添加到最终生产版本

有关此方法的更多详细信息，请参阅。
我们的做法不同。我想我们如何更轻松地做到这一点：在
master
中，我们正在开发下一个主要版本

每个较大的特征都有其自己的分支（从主特征派生），并将重设基础（+强制推动）开发人员定期在主功能的基础上重新设置基址。只有在单个开发人员使用此功能时，重新设置基址才能正常工作。如果该功能完成，它将重新设置基址到主功能上，然后主功能快速转发到最新的功能提交

为了避免重定基址/强制推送，还可以定期将主功能更改合并到功能分支，如果完成了，则将功能分支合并到主功能（普通合并或挤压合并）。但IMHO这会降低功能分支的清晰度，并使重新排序/清理提交变得更加困难

如果一个新版本即将发布，我们将在master之外创建一个分支，例如，
release-5
，其中只修复bug。
git最好的一点是，您可以更改最适合您的工作流程。我确实使用了大部分时间，但您可以使用任何适合您需要的工作流。
事实上，这让人如此困惑Beanstalk人支持他们非常非标准的登台使用（在他们的图表中，登台是在开发之前出现的，这不是一个错误

+1表示“一个成功的Git分支模型”。这基本上已经成为Git工作流的标准。“一个成功的Git分支模型”对于只有很少人参与的小型项目来说，这有点复杂。我更喜欢更简单的方法，在主分支中进行开发，在主分支中标记稳定版本，如果需要的话，它们有用于补丁的稳定分支。请参阅并感谢@JosefKufner，github flow文章非常有用helpful@eykanal您是否合并
development
进入
生产
或
功能
进入
生产
？在本文中没有登台分支。它们如何从开发服务器部署到登台？我只看到它们如何从开发直接部署到生产-将开发分支合并到主机，但这并不安全，因为它跳过了登台环境，不是吗“不是吗？您可能希望将修复程序从暂存合并到生产。为了测试目的而将修复程序合并到暂存，然后在测试完成后将开发合并到生产，这样就有可能将从未合并到暂存的其他开发工作合并到生产中。传统的分支工作流不容易执行。”作为Git中的分支，Play到Git要轻得多。它们只是指向历史中（单个）提交的指针，而历史本身可以向多个方向分支。这就是为什么很难将分支视为独立开发的“线”（这也适用于“成功的Git分支模型”中的图表）.是的，这不完全是泳道。但我的问题更具体：我是否切换到登台并合并到开发，或者反之亦然？我是git新手，对此感到困惑。也许我应该直接向我的windows git客户端SmartGit的制造商提出这个问题。这正是我一直在寻找的问题。搜索Google并在first num上找到了这个问题我不知道这是什么意思。你有什么特别不明白的？