需要分行计划吗? [英] Branching plan required?

问题描述

在 TFS 分支指南 2010 v1(此处)中，ALM Rangers 为您提供了 4 个分支计划(场景)目前.

In the TFS Branching Guide 2010 v1 (here) the ALM Rangers gives you 4 branch plans (scenarios) at the moment.

但在一个相关项目中，TFS 指南，同样来自 ALM Rangers (此处)，他们提供了无分支"方案.这是一个很好的起点，因为例如有 2 个分支(dev 和 main)会减慢速度，并且由于所有 FI(前向积分)和 RI(反向积分)处理会引入更多的复杂性.

But in a related project, TFS Guide, also from the ALM Rangers (here), they offer a scenario "No Branch". This is good starting point, because having for example 2 branches (dev and main) will slow down the velocity and does introduce more complexity because of all the FI (forward integrate) and RI (reverse integrate) handling.

在我看来，ALM Rangers 不会同步两个项目，因为分支指南 2010 v1 不再提供无分支"计划......

It looks for me that ALM Rangers do not sync both projects, because the branching guide 2010 v1 is not offering the "No Branch" plan anymore....

对于我们的公司，我们希望定义一个指导方针，说明在开始时使用一个简单的模型，但能够在需要时发展壮大.所以实际上，我们只想直接在 Main 分支上开始使用和开发，当 QA 真的成为一个问题时，我们可以开车到一个开发分支并沿着这些分支合并.

For our company we want to define a guidance that says to use a simple model at start but has the capability to grow when needed. So in fact, we want to start to use and develop directly on the Main branch only, and when QA really will becomes an issue we can drive off to a development branch and merge along the branches.

这是一个值得遵循的好习惯吗?

Is this a good practice to follow ?

推荐答案

如何分支是您在源代码配置管理方面可以做出的最重要的决定之一.它需要与您的组织、流程和团队相匹配.

How you branch is one of the most important decisions you can make with respect to source code configuration management. It needs to match your organization, your processes, and your teams.

你早期决定的东西在很大程度上将是你最终永远使用的东西，所以不要轻易做出决定.

What you decide early will be, to a great degree, what you wind up using forever, so don't take the decision lightly.

我个人的建议(只是因为它对我们有用)是使用 MAIN 和 DEV 分支方法.这提供了在合并到 MAIN 分支之前执行一定级别的质量保证(例如试构建)的能力.DEV 分支成为您的主要集成分支，因此前向集成不是一个负担(因为每个人都在 DEV 分支工作).

My personal recommendation (only because it works for us) is to use the MAIN and DEV branch approach. This provides the ability to perform a level of quality assurance (e.g. trial builds) prior to merging to the MAIN branch. The DEV branch becomes your primary integration branch, so forward integration isn't as much of a burden (since everyone is working off of the DEV branch).

为了给您一些参考，我们实际上花了 3 到 6 个月的时间讨论我们的分支策略，通过用例运行它并尝试在其中找到漏洞，然后才决定使用哪个.

Just to give you some reference, we literally spent between 3 and 6 months discussing our branching strategy, running it through use cases and trying to poke holes in it, before we decided which one to use.

这篇关于需要分行计划吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！