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

时间:2015-10-19 14:40:46

标签: tfs branching-and-merging azure-devops branching-strategy

我们有两个分支机构; 开发(开发人员定期检查/集成)和 Main (开发代码合并到版本/发布中)。

在阅读有关分支“策略”/“最佳做法”的内容时,据说开发必须是 主要分支。 开发必须 分支。

例如,在阅读VS ALM Ranger的Branching Strategies document中的开发隔离时,它会说明“开发分支应该是主分支的完整子分支”

为什么主要不能成为开发的完整分支?根据我的理解,开发几乎总是包含主要所拥有的所有内容(不包括修补程序)。

开发合并到主要是更常见的情况。在这种情况下,甚至是“原始”,哪个是分支?

注意:我们正在使用Visual Studio Team Services

1 个答案:

答案 0 :(得分:1)

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

- 主分支(此分支将反映当前部署的代码)

- 暂存分支(此分支将充当QA的测试环境。如果在您的情况下没有意义,可以将其删除。)

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

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

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

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

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

TFS: Merge best practices