为什么我们需要dev分支？

Question

我看到有些人使用dev旁边的分支master来开发环境.即使他们使用功能分支,他们也​​说有dev分支更好.我实际上没有听到合适的答案.即使有dev分支,仍然必须在推动之前完成工作.(http://nvie.com/posts/a-successful-git-branching-model/)

我真的不明白.毕竟我为什么需要开发分支.

• 我使用master分支作为我的开发分支.
• 我的任何撤消作品都在特色分支中.每当我完成功能分支中的工作时,我会将其合并到master中.
• 任何时候我需要发布,我正在标记大师.
• 如果我有测试,登台或preprod环境,我也有这些分支.

就这样.这个流程为我修复了一切.我认为没有任何理由有dev分支.

我想念什么案例？使用master开发环境有什么问题？你使用dev分支的情况如果你这样做？

Answer 1

Master 分支是您生产的一个工作分支，它必须没有错误、经过良好测试并包含稳定的代码。然而，开发分支可能包含问题和其他复杂性。

假设您已经在 master 分支上从 dev 服务器提交了您的开发，您进行了登台，但不幸的是它在登台服务器设置上产生了问题，您返回开发并修复它。在这之间，客户端要求紧急修补程序，您希望在实时服务器上紧急推送一些更改。在这种情况下，再次恢复和更改文件可能是一项非常艰巨的工作。

相反，如果你只为 live 保留 master 分支，为开发环境保留 dev 分支，为测试和登台环境保留 stage 分支。

您在 dev 分支上开发，将其推送到 staging，如果可行，将其与 staging 分支合并，如果没有，则返回 dev，修复它，然后再次推送。如果舞台都设置好了，你就可以把它拉下来。检查一段时间。如果有问题，立即 checkout 到 master，修复它，再次 push stage，一旦所有设置，与 master 合并并在 master 中 checkout 作为当前分支。

在这种情况下，如果客户端要求实时更改紧急更改，您可以在开发服务器上检出 master 分支，从中创建一个新分支（永远不要直接更改为 master），修复它，在舞台上推送，然后在实时推送。在这个匆忙中，如果修复出错，您可以随时结帐到 master，如果正确则将其与 master 合并。

在这种情况下，您在开发服务器上的 dev 分支未受影响，这更容易再次开始您的开发。

Answer 2

我建议您使用 dev 分支。

我通常遵循以下经验法则：

• 代码中的小改动在“开发”分支上进行。

• 几个人将在他们自己的“功能”分支上工作的主要功能。

• master 分支上的小错误修复在他们自己的分支上进行，称为“热修复”，并立即合并回 master 分支。

最后的所有内容都合并到 master 中。Master 应该被认为是你向公众发布的发布分支。它应该是经过测试并被认为是稳定的代码。

更详细的解释在这里：https : //www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow