我们这样设置的原因是，主分支将反映服务器上当前部署的代码。这样，如果我们确实需要做一个热修复，它可以完全与当前的开发周期隔离，所以我们正在做的任何事情都不会潜入修复。
我们有两个分支;Development(开发人员定期检查/集成到其中)和Main(来自Development的代码被合并到其中以进行版本控制/发布)
在阅读分支"策略"/"最佳实践"时，据说Development必须是 Main的分支。Development必须是Main的分支。
例如，当阅读VS ALM Ranger的分支策略文档中的开发隔离时，它说如何"开发分支应该是主分支的完整子分支"。
为什么Main不能是Development的一个完整分支?从我的理解来看，Development几乎总是包含Main拥有的所有内容(不包括hotfixes)。
从Development合并到Main是更常见的场景。在这种情况下，哪个是"原始"哪个是分支有关系吗?
注意:我们使用的是Visual Studio Team Services
在我使用TFS的所有经验中，我们使用以下模式:
-主分支(该分支将反映当前部署的代码)
—暂存分支(此分支将作为QA的测试环境。如果它在您的情况下没有意义，可以将其删除。
—开发分支(这是开发人员将定期签入的分支)
我们这样设置的原因是，主分支将反映服务器上当前部署的代码。这样，如果我们确实需要做一个热修复，它可以完全与当前的开发周期隔离，所以我们正在做的任何事情都不会潜入修复。
分级分支将是QA部门执行其验证的主要位置。有些组织的处理方式不同，所以这可能不适用于您的情况。
开发分支将是最"实验性"的分支。这是最有可能出现漏洞和一般开发人员恶作剧的。向上合并以推送更改，向下合并以获得更新的更改。我偶然发现了一篇关于最佳合并实践的更好解释的文章。这应该可以回答我所引入的任何困惑(:
TFS: Merge best practices