为什么我们需要dev分支？

Question

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

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

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

多数民众赞成。这个流程为我修复了一切。我认为没有任何理由让dev分支。

我错过了什么案例？使用master作为开发环境有什么问题？如果你使用dev分支的哪种情况？

Answer 1

我建议你使用dev分支。

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

• 代码中的细微变化继续发展＆＃34;开发＆＃34;科。

• 几个人将要开发的主要功能是自己的功能＆＃34;功能＆＃34;分支。

• 主分支上的小错误修复程序在他们自己的分支上进行，名为＆＃34; hot fix＆＃34;并立即合并回主分支。

最后的一切都会合并到主人身上。师父应被视为向公众发布的发布分支。它应该是已经过测试且被认为是稳定的代码。

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

Answer 2

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

让我们说，你已经从master分支上的dev服务器提交了你的开发，你进行了升级，不幸的是它会产生问题w.r.t.登台服务器设置，您返回开发并修复它。在此之间，客户端请求紧急修补程序，您希望在实时服务器上紧急推送一些更改。在这种情况下，这种恢复和更改文件可能是一项疯狂的艰苦工作。

相反，如果您只为开发环境的live，dev分支，测试阶段分支和暂存环境保留master分支。

您在dev分支上开发，将其推送到暂存，如果工作将其与暂存分支合并，如果没有，请返回dev，修复它然后再次推送。如果阶段已全部设定，则将其拉到现场。检查一下。如果有问题，请立即签出以掌握，修复，再次推送阶段，一旦完成设置，与master合并，并将master作为当前分支合并。

在这种情况下，如果客户端要求对live进行紧急更改，请在开发服务器上签出master branch，从中创建一个新分支（永远不要直接更改为master），修复它，推送到舞台然后继续直播。在这种情况下，如果修复出错，您可以随时签出以掌握，如果正确，则将其与主人合并。

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