首页 文章

开发隔离分支策略:分支的起源?

提问于
浏览
0

我们有两个分支机构; Development (开发人员定期检查/集成)和 Main (其中来自Development的代码合并为版本控制/发布) .

在阅读有关分支"strategies" / "best practices"时,据说 Development 必须是 Main 的分支 . Development 必须从 Main 分支 .

例如,在阅读VS ALM Ranger的Branching Strategies document中的开发隔离时,它会说明如何"the development branch should be a full child branch of the main branch" .

为什么 Main 不能成为 Development 的完整分支?根据我的理解, Development 几乎总是包含 Main 具有的所有内容(不包括修补程序) .

Development 合并到 Main 是更常见的情况 . 在这种情况下甚至是"original",哪个是分支?

注意:我们使用的是Visual Studio Team Services

1 回答

  • 1

    在使用TFS的所有经验中,我们使用以下模式:

    • Main Branch (此分支将反映当前部署的代码)

    • Staging Branch (此分支将作为QA的测试环境 . 如果在您的情况下没有意义,可以将其删除 . )

    --- Development Branch (这是开发人员定期检查的分支 . )


    我们在此设置背后的理由是 main branch 将反映服务器上当前部署的代码 . 这样,如果我们确实需要进行热修复,它可以完全与当前开发周期隔离,因此我们正在处理的任何内容都不会进入修复程序 .

    staging branch 将基本上是您的QA部门将执行其验证的地方 . 有些组织处理方式不同,因此这可能不适用于您的情况 .

    development branch 将是最多"experimental"分支 . 这具有最大的潜在错误和一般开发人员的恶作剧 . 我们将这个分支放在底部,因为如果开发人员发现他/她自己需要在任何原因下从开发分支创建分支,那么信息流将是有意义的 . 合并以推送更改,并合并以获取更新的更改 .

    我偶然发现这篇文章对最佳合并实践有了更好的解释 . 这应该回答我介绍的任何困惑(:

    TFS: Merge best practices

相关问题