活分支数量的最佳范围是多少？ [英] What is the optimal range for number of live branches?

问题描述

我们假设一个项目是：

• 1 产品
包含 M 的

• 
  
• 构建于 Y 在 L [1..3]语言


• 中创建的模块


• D 开发人员

项目包含太多或太少直播分支？

我知道这是一个很难回答的问题，它更难以用数字来回答，但是我正在寻找量化的答案，如果可能的话，请做一个公式。

背景

如果分支太少，代码永远不会准备好，开发人员不会做很大的变化，因为它可能不可能满足下一个最后期限。同样，产品经理从来没有足够的信心来命名发布。功能冻结通常会建立，新的想法被延迟，发展速度会减慢。

如果分支太多，开发人员不确定他们的更改应该到哪里以及他们应该在哪里被传播，哪个分支将被合并到哪个中继线。合并重构代码非常困难，质量下降。此外，每个开发者都必须在几个设置中测试他们的变化，相当大的努力被浪费了，开发速度减慢了。

活动分支数量的最佳范围是什么？

解决方案

确定RCS（svn或git）包含太多分支的经验法则是什么？

3的规则：

• 稳定代码的一个分支 - 主干线;


• 不稳定 - 即将发布的开发版本的一个分支;
  
• 另外还有一个用于维护的版本 - 以前版本的bug修复程序;
  

$ b 许多git托管的项目只使用两个分支：























$ b $使用标签功能标记开发中的里程碑。

em这些远程分支取决于他们正在执行的任务。

请开发人员为本地分支添加有意义的名称和描述。并且标签相应地提交。

Let's say a project is:

• 1 product
• built over Y years
• comprising M modules
• written in L [1..3] languages
• developed by total of D developers

At what point does a project contain too many or too few live branches?

I know it is a hard question, it is even harder to answer numerically, I am however looking for quantified answers, if at all possible, please make a formula.

Background

If there are too few branches, code is never ready, developers don't make large changes because it may be impossible to meet next deadline. Likewise product managers never feel confident enough to name something a release. Feature freeze is often established, new ideas are delayed, development slows down.

If there are too many branches, developers are unsure where their changes should go and where they ought to be propagated, which branch will be merged to which trunk. Merging refactored code is very hard., quality goes down. Moreover, each developer has to test their changes in several setups, considerable effort is wasted, development slows down.

What is the optimal range for number of live branches?

解决方案

What is the rule of thumb to determine that RCS (svn or git) contains too many branches?

How about rule of 3:

• One branch for stable code — main trunk;
• One branch for unstable — upcoming release development;
• And one more for maintenance — previous release's bug-fixes;

Many git-hosted projects use only two branches: master for main trunk and vNext for future release.

Use tags feature for labeling milestones in your development.

Please allow your developers to create development branches locally and merge them to these remote branches depending on the task they are performing.

Ask developers to add meaningful names and descriptions to the local branches. And label commits accordingly.

这篇关于活分支数量的最佳范围是多少？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！