是否可以创建一个钩子，拒绝，从分支创建分支的能力？
只允许它从行李箱？
如果是这样，那将是怎样的？
答案 0 :(得分：1)
是的，可以使用预提交钩子，但你会后悔的。有时您可能会创建分支的分支。假设您对该分支进行了长期修复，并希望创建功能分支。在这种情况下，您需要从分支机构中分支。
让我们深入了解你的问题：你是如何进行发展的？太多站点（即大于零）使用原始主干方法。这个想法是没有在干线上进行开发。相反，您创建一个分支，在分支上执行所有工作，然后将该分支合并到主干，然后为下一个版本创建一个新分支。其中一个最大的问题是开发人员忘记合并到trunk，并从trunk创建一个新的分支。从当前分支创建下一个分支变得更加容易。
原始树干不是一种好的方法。它很复杂，很难进行并行开发，当你接近发布时（特别是因为你不想创建分支的分支）。并且，它没有给你买任何东西。 Trunk被认为是最后一个版本，但是你可以从标签中获得相同的信息。
更糟糕的是，除了最后一个版本（在HEAD上）之外，trunk无法告诉你任何事情。干线上的先前版本？你不能说。有些文件在上一次发布期间发生了变化，而其他文件则没有。这就是你使用标签的原因。也不能从树干上得到任何历史记录。是谁改变了？你没有看到改变的作者。相反，您会看到将分支合并为主干的人。
如果您使用原始主干方法，请停止。
如果你没有采用原始主干方法，我很高兴听到这个。忽略上面的咆哮。
你真正想做的不是阻止分支的分支，而是限制谁可以创建分支以及他们可以在哪里创建这个分支。例如，发布分支应该只由CM完成。可以由团队负责人创建功能分支。您可以使用命名约定来区分这些不同的分支类型，甚至将它们放在特殊目录下。 （例如branches/releases vs.＆＃39; branches / other`）。
我有一个pre-commit hook可以帮助这项工作。它可以限制谁可以创建分支，以及他们可以在何处以及可以称之为分支的内容。
答案 1 :(得分：0)
在我原来的回答中，我特别说 pristine trunk 方法存在缺陷，我没有提及替代方案。我是故意这样做的，因为有很多方法。最受欢迎的两种称为 unstable trunk 和基于流的开发。
在此，您有两个独立的流：集成流和开发流。在大多数情况下， streams 通常实现为分支。在Subversion中，集成流可以是主干。开发人员可以拥有多个开发流，这些开发流几乎可以代表任何东西。开发人员可以有一个或两个流进行基本开发。也许是长期特征的另一个。有些地方每个问题都有一个单独的流。
典型的工作流程是：
这种方法在Git中非常常见，其中每个本地Git存储库都可以被认为是开发流，而主存储库被认为是集成流。它也常用于敏捷开发。
这种方法在20世纪90年代开始使用ClearCase，然后随着Perforce，CVS和Subversion变得更受欢迎而失去了它的受欢迎程度。现在它更流行，因为Git看起来很自然。
事实上，基于Steam的开发甚至更早出现在Sablime。 Sablime基于SCCS，但其上加有修改请求（MR）系统。在Sablime中，当您检查更改时，它必须针对一个或多个MR。基线称为 Generic ，下一个 Generic 是通过将一组 MRs 应用于先前的Generic而生成的。
不稳定主干方法在2000年左右出现了基于流的开发问题。一个是基于流的开发涉及很多合并。另外，它似乎需要大量的马力才能实现。在CM世界中有一种说法，分支就像孩子一样：如果你拥有它们，你必须好好照顾它们并仔细观察它们。
随着CruiseControl等持续集成系统的出现， unstable trunk 方法开始发挥作用。在 unstable trunk 中，几乎所有工作都必须在主干（或某种类型的集成蒸汽）上完成。分支是在某个未定义的时间完成的，您可以在当前版本上开始提供代码，同时希望继续处理下一个版本。有些网站，这是你最终提出候选发布的时候。在其他站点，可能是发布时功能完成。它基本上是在您不再需要整个开发团队处理一个版本的时候。在只有几个开发人员的非常小的站点中，永远不会创建发布分支。顺便说一句，两种方法都在分支上创建和发布。这是因为在基于流的开发和不稳定主干中，您可能会达到某些人正在处理2.1版本而其他人正在处理2.2发布。在 unstable trunk 中，您将其称为发布分支。在基于流的开发中，您只需将其称为另一个集成流。
两者之间的最大区别在于您决定添加哪些功能以及何时添加。在 unstable trunk 中，这必须在开发周期的开始（或者可能在敏捷Sprint的开始）完成。您必须完成，因为您的开发取决于实现一个更改问题，然后是下一个。
在基于流的开发中，这可以延迟到循环结束。您可以处理问题1001,1002,1003,1004，然后决定只需要将问题1002和1004传递到集成流。
基于流的开发的主要问题以及它失去普及的原因是您意识到您正在创建不再相关的代码流。例如，我正在处理问题1004.问题1001,1002和1003已经完成，但没有交付，因此我正在开发一个代码库，但不包含其他开发人员所做的更改已经完成了。
另外，合并是一件麻烦事。您将遇到合并冲突，这意味着开发人员必须花时间在开发上调试和测试合并。
基于流的开发还意味着在实际交付代码之前不能进行测试。你迟迟没有提供更改，可以进行任何类型的测试。
有办法解决这些问题。敏捷开发在每个sprint结束时将开发削减为sprint并强制交付。一个版本可能包含3到4个冲刺，最后的第5个sprint用于清理。
这使得基于流的开发更像是不稳定的主干，但您仍然可以在冲刺结束时进行选择。例如，当团队意识到编码没有按照应有的方式进行时，开发人员正在处理特定问题。可能有决定不在此sprint中包含此特定流，并且可能会考虑重新实现该功能的新方法。
基于流的开发对代码审核也更友好，因为代码已提交，但尚未在交付流中。
不稳定主干的主要优点是简单性，并迫使开发人员在进行更改时采取较小的咬伤。特定的变化可能分几个阶段而不是一次完成。它还使得持续集成和QA测试变得更容易，因为QA测试几乎可以在开发过程中的任何地方进行。
基于流的开发更受开发人员和项目经理的欢迎。开发人员可以按照他们想要的方式进行更改，项目经理可以推迟在发布结束之前提供哪些功能。\
不稳定主干在QA，技术主管和CM中更受欢迎。 QA可以提前进行测试，并在急于发布之前发现问题。 CM喜欢它，因为跟踪的分支较少，技术经理喜欢它，因为它对开发的监督较少。
这些方法都不是自动，不同的工具往往适合不同的做法。 CVS对基于流的开发没用，因为分支和合并非常昂贵。然而，它与 unstable trunk 非常吻合。 Git在基于流的开发中运行良好，但与 unstable trunk 一起使用时只会成为负担。
CVS，Perforce和Subversion往往与 unstable trunk 配合使用效果最佳。虽然Subversion分支是一个最小的成本，但合并仍然是一个相当草率的操作。 Git倾向于使用基于流的开发。