1

是否可以创建一个钩子，拒绝从一个分支创建一个分支的能力？
只允许从后备箱？
如果有，会怎样？

4

2 回答 2

1

是的，使用预提交挂钩是可能的，但你会后悔的。有时您可能会从一个分支创建一个分支。假设您对该分支进行了长期修复，并且想要创建一个功能分支。在这种情况下，您需要从您的分支中创建一个分支。

让我们来看看你的问题的实质：你是如何进行开发的？太多的站点（即多于零个）使用原始主干方法。这个想法是开发不是在主干上完成的。相反，您创建一个分支，在该分支上完成所有工作，然后将该分支合并到主干中，然后为下一个版本创建一个新分支。最大的问题之一是开发人员忘记合并到主干，并从主干创建一个新分支。从当前分支创建下一个分支要容易得多。

原始树干不是一个好的方法。这很复杂，当您接近发布时很难进行并行开发（特别是因为您不想从分支创建分支）。而且，它什么也没给你买。Trunk 应该是最后一个版本，但您可以从标签中获得相同的信息。

HEAD更糟糕的是，除了最后一个版本（on ）之外，trunk 无法告诉您任何信息。主干上的先前版本？你说不出来。一些文件在上次发布期间发生了变化，而另一些则没有。这就是你使用标签的原因。你也不能从主干中获取任何历史记录。是谁做出了这样的改变？您看不到更改的作者。相反，您会看到将分支合并到主干的人。

如果您使用原始的主干方法，请停止。

如果您没有采用原始的树干方法，我很高兴听到这个消息。无视上面的吐槽。

你真正想做的不是阻止分支的分支，而是限制谁可以创建分支以及他们可以在哪里创建这个分支。例如，发布分支只能由 CM 完成。功能分支可以由团队负责人创建。您可以使用命名约定来区分这些不同的分支类型，甚至可以将它们放在特殊目录下。（branches/releases例如与“分支/其他”）。

我有一个预提交钩子可以帮助完成这项工作。它可以限制谁可以创建一个分支，以及他们可以在哪里以及可以调用什么分支。

于 2013-04-22T18:22:52.693 回答
0

在我最初的回答中，我特别说原始的树干方法是有缺陷的，我没有提到替代方案。我是故意这样做的，因为有很多方法。最流行的两种称为不稳定的主干和基于流的开发。

基于流的开发

在此，您有两个独立的流：一个集成流和一个开发流。在大多数情况下，流通常实现为分支。在 Subversion 中，集成流可以是主干。开发人员可以有多个开发流，这些开发流几乎可以代表任何东西。开发人员可以有一个或两个流用于基本开发。也许另一个长期功能。有些地方对每个问题都有单独的流。

典型的工作流程是：

  • 开发人员从集成流（又名分支）创建开发流。
  • 开发人员做他们的工作。
  • 开发人员从集成流中变基他们的流。（又名从主干合并到分支）
  • 开发人员完成测试，并将他们的开发流交付回集成流（也称为合并到主干）。
  • 开发人员重复这个过程，直到项目完成，否则他们就死了。

这种方法在 Git 中非常常见，其中每个本地 Git 存储库都可以被认为是一个开发流，而主存储库被认为是集成流。它也常用于敏捷开发。

这种方法论始于 1990 年代的 ClearCase，然后随着 Perforce、CVS 和 Subversion 变得越来越流行而失去了它的流行度。它现在更流行，因为它在 Git 中看起来很自然。

事实上，基于 Steam 的开发早在 Sablime 就出现了。Sablime 基于 SCCS，但附加了修改请求 (MR) 系统。在 Sablime 中，当您签入更改时，必须针对一个或多个 MR。基线称为Generic，下一个Generic是通过将一组MR应用于前一个 Generic 来生成的。

不稳定的树干

不稳定的主干方法是在 2000 年左右从基于流的开发问题中产生的。一是基于流的开发涉及大量合并。另一个，实施起来似乎需要很大的动力。CM界有句俗话说，树枝就像孩子一样：有就得好好照顾，看得很仔细。

随着 CruiseControl 等持续集成系统的出现，不稳定的主干方法开始发挥作用。在不稳定的主干中，几乎所有的工作都必须在主干上完成（或某种类型的集成蒸汽）。分支在某个未定义的时间完成，您开始在当前版本上交付代码，同时希望继续在下一个版本上工作。有些网站，这是您最终提出候选版本的时候。在其他站点，可能是在发布Feature Complete的时候。基本上是在您不再需要整个开发团队都在一个版本上工作的时候。在只有几个开发人员的非常小的站点中，永远不会创建发布分支。

顺便说一句，这两种方法都在分支上创建和发布。这是因为在基于流的开发和不稳定的主干中，您可能会遇到一些人正在开发 2.1 版本而其他人正在开发 2.2 版本的地步。在不稳定的主干中，你称它为发布分支。在基于流的开发中，您只需将其称为另一个集成流。

两者之间的最大区别在于您何时决定添加哪些功能以及何时添加。在不稳定的主干中，这必须在开发周期的开始（或者可能在敏捷 Sprint 的开始）完成。您必须这样做，因为您的开发取决于实施一个变更问题，然后是下一个变更问题。

在基于流的开发中，这可以延迟到周期结束。您可以处理问题 1001、1002、1003、1004，然后决定只希望将问题 1002 和 1004 交付到集成流。

基于流的开发的主要问题以及它失去流行的原因是意识到您正在使用不再相关的代码创建流。例如，我正在处理问题 1004。问题 1001、1002 和 1003 已完成，但尚未交付，因此我正在处理不包含其他开发人员所做更改的代码库。

另外，合并很麻烦。您将遇到合并冲突，这意味着开发人员必须从开发中抽出时间来调试和测试合并。

基于流的开发还意味着在实际交付代码之前无法进行测试。您推迟交付更改的时间越晚，进行的任何类型的测试就越少。

有一些方法可以解决这些问题。敏捷开发将开发分成多个冲刺，并在每个冲刺结束时强制交付。一个版本可能包含 3 到 4 个 sprint，最后是第 5 个 sprint 进行清理。

这推动基于流的开发更像是不稳定的主干，但您仍然可以在 sprint 结束时进行选择。例如，当团队意识到编码没有按照应有的方式进行时，开发人员正在处理特定问题。可能会决定不在这个 sprint 中包含这个特定的流，并且可能会想一种新的方法来重新实现这个特性。

基于流的开发对代码审查也更友好，因为代码已提交，但尚未在交付流中。

不稳定的主干的主要优点是简单，并迫使开发人员在进行更改时采取较小的措施。一项特定的更改可能会分几个阶段实施，而不是一次全部实施。它还使持续集成和 QA 测试变得更容易，因为 QA 测试几乎可以在开发期间的任何地方进行。

基于流的开发更受开发人员和项目经理的欢迎。开发人员可以按照他们想要的方式进行更改，项目经理可以推迟交付哪些功能，直到发布结束。\

不稳定的主干更受 QA、技术主管和 CM 的欢迎。QA 可以更早地进行测试，并在急于发布之前发现问题。CM 喜欢它是因为要跟踪的分支更少，技术经理喜欢它是因为它对开发的监督更少。

这两种方法都不是自动的，不同的工具往往适合不同的实践。CVS 对基于流的开发毫无用处，因为分支和合并非常昂贵。然而，它在不稳定的主干上工作得很好。Git 非常适合基于流的开发，但在与不稳定的主干一起使用时只会成为负担。

CVS、Perforce 和 Subversion 往往最适用于不稳定的 trunk。尽管 Subversion 分支的成本最低，但合并仍然是一个相当草率的操作。Git 倾向于使用基于流的开发。

于 2013-04-23T14:34:22.650 回答