活枝数量的最佳范围是多少？

Question

假设一个项目是:

• 1 产品
• 建立Y多年
• 包含M模块
• 用L[1..3]种语言写成
• 由D开发人员共同开发

项目在什么时候包含太多或太少的实时分支？

我知道这是一个很难回答的问题,在数字上更难回答,但我正在寻找量化的答案,如果可能的话,请制定一个公式.

背景

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

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

活枝数量的最佳范围是多少？

Answer 1

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

恕我直言,一旦分支已经失去其实用性(例如,所有变化合并回主干,或者已经放弃或结束的失败的实验/研究项目),它应该被删除.如果需要,你可以随时取回它,这将有助于使事情变得更加整洁.

基于你的编辑:如果有分支过时或"死",为什么它们还在？根据定义,它们不再有用,所以只需删除它们即可.

Answer 2

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

怎么样rule of 3:

• 稳定代码的一个分支 - 主干;
• 不稳定的一个分支 - 即将发布的版本;
• 还有一个用于维护 - 以前的版本的错误修复;

许多git托管的项目只使用两个分支:master主干和vNext未来版本.

使用tags功能标记开发中的里程碑.

请允许开发人员在本地创建开发分支,并根据他们执行的任务将它们合并到这些远程分支.

要求开发人员向本地分支添加有意义的名称和描述.并标签提交相应的.

Answer 3

如果你使用git有多个分支可能是有用的,即使它们已经死了.您可以跟踪引入错误的产品版本(按版本分类),您可以为许多小团队组织工作.你可以看到为什么有些想法只是通过查看死枝来解决问题.

关键是一致性.尝试将分支分组以适合您的工作流程.你可以举例说

• stable - CI从此构建生产和/或升级
• staging - CI构建从这个开始
• feature/* - 功能分支
• hotfix/* - 从staging/stable分支开始,用于修补程序
• experimental/* - 用于研发功能,可能不会产生干净和可维护的代码,或者可能在中途被废弃

一些基本提示:http: //nvie.com/posts/a-successful-git-branching-model/

此外,如果您希望您的团队快速开始使用一个好的分支结构,请尝试git flow:http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

关于重构其他同事的坏代码.您可以使用一些refactor/*分支,这样您就可以通过在单独的分支上进行合并/重组原子来轻松查看损坏的内容.当然,测试非常有用,但是如果你没有,那么一个简单的git bisect会告诉你谁和何时引入了一个bug(如果你编写一个测试来检查这个错误哪个bisect会使用你现在有一个有意义的测试添加到你的测试套件).

底线是:不要害怕拥有多个分支,只要保持它们井井有条.合并大部分时间并不像人们所说的那么复杂,你可以随时撤消它们(如果不使用连续交付模式,则推迟到下一个版本).

编辑:something/*我的意思是拥有多个具有公共something/前缀的分支,从而模仿目录结构.

EDIT2:SVN喜欢的东西不同,分支和合并并不便宜.谨慎行事;)

编辑3:考虑为不同的模块使用不同的(子)存储库.它可能会简化开发.模块开发人员只关心主应用程序的最新稳定版本,而分支模型仅面向一个模块.

EDIT4:问:"你是否可以考虑将一些数字或公式置于阈值之下,在这个阈值之下可以接受凌乱的分支,哪个分支更好地组织起来？"

当然!

公式(以我的拙见)很简单.

• 在本地拥有尽可能多的"脏"分支(只是不要将它们推送给其他人或共享存储库)
• 尽量不要推动脏分支,除非它们代表其他开发人员的某些价值.如果你已经将它们放在共享存储库中,请保留它们并重命名它们(legacy/*或者dirty/*想到它).

将它们视为文件结构.您可以不再需要许多旧文件,但如果以有组织的方式保留它们,则可以轻松地将存档与工作集分开.

看到你喜欢的数字你可能想要这些分支的真实世界用例

让我举一个我一直在研究的中小型Symfony2 PHP项目的例子.

如果您有一个项目持续6-9个月,由5位开发人员以敏捷(scrum)方式积极开发,每两周进行一次客户端演示,您可能希望拥有分支机构:

• 每个用户的故事(关于紧密集成的用户故事,这可能是一个坏主意),总共约50个分支,将它们视为功能分支
• 每个开发人员(根据需要,如果开发人员需要暂时处理某些事情),他们来去匆匆,但通常开发人员在这类项目中的数量少于3个.他们中的一些根本不使用公共开发人员分支,并将自己的脏分支保留给自己
• 实验(用于研究目的的无限数量的分支,例如模块中使用的不同算法或库),据我记得大约7个分支
• 每个sprint(从用户故事中合并,有助于演示),大约10个,这些我们在初始开发期间是我们的升级/稳定.为什么不用标签？标签也是,但分支,因为它更容易应用修补程序.
• 修补程序(通常是短暂的,隔离的,以便于采摘樱桃),3个顶部;)
• misc(通常是正在进行的全系统功能和/或2-3人团队分支),大约10

正如你所看到的,这里也没有确切的数字.我做了几个这样大小的项目,其中大多数都有大约70-80个分支(20-30个没有用户故事分支).如果它们以逻辑,干净的方式组织,则代码存储库易于浏览.

使用git也考虑重新绑定而不是合并,因此你不会得到合并泡沫(请查看这篇文章http://stevenharman.net/git-pull-with-automatic-rebase).