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

假设一个项目是：

• 1

  产品
• 建造时间

  Y

  年
• 包含

  M

  模块
• 用

  L

  [1..3]种语言编写
• 由

  D

  开发人员共同开发

在什么情况下，项目包含的活动分支过多或过少

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

背景

若分支太少，代码就永远不会准备好，开发人员就不会进行大的更改，因为可能无法满足下一个截止日期。同样地，产品经理也从来没有足够的信心将某个产品命名为发行版。功能冻结经常被建立，新想法被延迟，开发速度减慢

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

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

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

没有。这样的通用规则并不存在，而且（如果仍然可以定义任何本地规则的话）最终会严重依赖于团队和工作流

使用“每个任务分支”时，即使是中小型代码库（适用于任何规模的团队和使用的语言数量），您也可能有许多短期分支

从评论中删除：

---

每个开发人员1-N个未关闭的任务分支（N取决于许多因素）每个开发人员1-2个活动的+一些公共共享的（稳定的-不稳定的-发布的…）

这个问题没有一个答案。它只能是“适用于您的组织和工作流的内容”

IMHO，一旦一个分支已经失效（例如，所有的变化都合并回主干，或者一个失败的实验/研究项目已经被放弃或结束），它应该被删除。如果你需要它，你可以随时取回它，这将有助于保持事物的整洁

---

根据您的编辑：如果有过时或“死”的分支，为什么它们仍然存在？根据定义，它们不再有用，所以只需删除它们。

git中的分支被认为是一次性的。如果你不需要它，也不再使用它，你就把它扔了。然而，就我而言，我确实管理了很多分支机构，但只有1%的分支机构在使用中。我已经锁定了其余部分，并确保已将正确的标记应用于发布版本

您可能需要定义所有相关分支是否同时处于活动状态。因为您可以有100个分支，但只有1个正在使用。但如果你有100个活跃的分支机构参与一个项目，那么是的，我会说这太多了，这只是表明管理不善

---

希望这有帮助

如果您想归档分支机构，我认为通常的解决方案是将它们推送到归档回购，然后删除它们；如果你想要它们回来，你知道去哪里找。

如果你在使用git，有多个分支是有用的，即使它们已经死了。您可以跟踪缺陷引入的产品版本（按版本平分），您可以为许多小型团队组织工作。你可以通过观察枯枝来了解为什么有些想法不奏效

关键是一致性。尝试对分支机构进行分组以适应您的工作流程。 例如，你可以

• stable

  -CI在此基础上构建生产和/或暂存

• staging

  -从该版本开始的CI生成staging

• feature/*

  -功能的分支

• hotfix/*

  -从暂存/稳定分支开始，用于修补程序

• 实验性/*

  -用于研发功能，这些功能可能不会产生干净且可维护的代码，或者可能中途放弃

以下是一些基本提示：

此外，如果您希望您的团队快速开始使用良好的分支结构，请尝试git flow：

关于重构其他同事的糟糕代码。您可以使用一些

refactor/*

分支，这样您就可以很容易地看到在单独的分支上进行合并/重基原子所破坏的内容。当然，进行测试是非常有用的，但如果您不这样做，一个简单的

git对分将向您显示谁以及何时引入了一个bug（如果您编写一个测试来检查这个bug，哪个对分将使用，那么您现在就有一个有意义的测试来添加到您的测试套件中）

底线是：不要害怕有很多分支机构，只要保持它们的组织性。大多数情况下，合并并不像人们说的那么复杂，您可以随时撤销它们（或者如果您不使用连续交付模型，可以推迟到下一个版本）

编辑：通过
something/*
我的意思是，有多个分支具有一个共同的
something/
前缀，从而模仿目录结构

EDIT2：SVN的情况不同，在SVN中，分支和合并并不是那么便宜。小心行事；）

 Ed3:考虑使用不同的（子）库来存储不同的模块。这可能会简化开发过程。模块开发人员只关心主应用程序的最新稳定版本，而分支模型只面向一个模块
问：“你能考虑把一些数字或公式放在阈值以下，杂乱分支是可以接受的，哪些分支更适合组织？”
当然

公式（依我拙见）很简单


在本地拥有尽可能多的“脏”分支（只是不要将它们推给其他人或共享存储库）
尽量不要推送脏分支，除非它们对其他开发人员有价值。如果您的共享存储中已经有它们