首页 / 知识

关于版本控制：您是继续在分支机构还是在主干中进行开发？

2023-04-13 16:42:00

Do you continue development in a branch or in the trunk?

假设您正在开发具有定期发布的软件产品。关于分支和合并的最佳实践是什么？将定期发布的分支切分给公众(或您的客户)，然后继续在主干上进行开发，或者将主干视为稳定版本，将其定期标记为发布，然后在分支中进行实验性工作。人们认为行李箱被认为是"金"还是被认为是"沙盒"？

我已经在大型商业应用中尝试了这两种方法。

哪种方法更好的答案很大程度上取决于您的实际情况，但是我将写出到目前为止我的总体经验。

总体上更好的方法(以我的经验)：中继线应始终保持稳定。

这是此方法的一些准则和好处：

将每个任务(或相关任务集)编码在其自己的分支中，这样您便可以灵活选择何时合并这些任务并执行发布。
在将每个分支合并到主干之前，应先对其进行质量检查。
通过对每个分支进行质量检查，您将确切地知道导致该错误的原因。
该解决方案可扩展到任意数量的开发人员。
由于分支是SVN中几乎立即的操作，因此该方法有效。
标记您执行的每个发行版。
您可以开发暂时不打算发布的功能，并确定何时合并它们。
对于您所做的所有工作，都可以受益于提交代码。如果仅在主干之外工作，则可能会使代码未提交很多，因此不受保护，并且没有自动历史记录。

如果您尝试相反的操作并在主干中进行所有开发，则会遇到以下问题：

日常构建中不断出现的构建问题
当开发人员向项目中的所有其他人提出问题时，生产力损失
发行周期更长，因为您最终需要获得稳定的版本
发行不稳定

如果您试图保持分支稳定并且将主干作为开发沙箱，那么您将根本没有所需的灵活性。原因是您无法从中继中选择要在该稳定版本中放入的内容。它将已经全部混入树干中。

我要说的是在主干中进行所有开发的一种情况是，当您开始一个新项目时。根据您的情况，可能还会有其他情况。

顺便说一下，分布式版本控制系统提供了更大的灵活性，我强烈建议切换到hg或git。

我已经使用了这两种技术，我会说在主干上进行开发并在发布时分叉稳定点是最好的方法。

那些反对的人说您将拥有：

Constant build problems for daily builds

Productivity loss when a a developer commits a problem for all
other people on the project

可能没有使用连续集成技术。

的确，如果您在一天中不执行几次测试构建，例如每小时大约进行一次，将使自己容易受到这些问题的困扰，这些问题将很快扼杀开发的步伐。

白天进行几次测试构建会迅速折叠到主要代码库的更新中，以便其他人可以使用它，并且如果有人破坏了构建，也可以在白天提醒您，以便他们可以在回家之前进行修复。

正如指出的那样，仅当夜间运行运行回归测试的构建失败时才发现损坏的构建是愚蠢的，并且会很快降低运行速度。

阅读Martin Fowler关于持续集成的论文。我们在Posix sh的大约2,000行中为大型项目(3,000kSLOC)推出了自己的系统。

我倾向于采用"发布分支"方法。中继线易失。一旦发布时间临近，我将创建一个发布分支，我将更加谨慎地对待它。最终完成后，我将标记/标记存储库的状态，以便知道"正式"发布的版本。

我知道还有其他方法可以做到-这只是我过去所做的方法。

都。

主干用于大多数开发。但是，预计将尽最大努力确保对行李箱的任何登机手续都不会中断。 (由自动构建和测试系统部分验证)

版本维护在其自己的目录中，仅对其进行错误修复(然后合并到主干)。

任何将使中继线处于不稳定或不工作状态的新功能都在其自己的单独分支中完成，然后在完成时合并到中继线中。

我喜欢并使用Henrik Kniberg在"多个敏捷团队的版本控制"中描述的方法。 Henrik在解释如何在具有多个团队的敏捷环境中处理版本控制方面做得非常出色(在传统环境中也适用于单个团队)，并且对他的措辞毫无意义，所以我只发布"备忘单"(自我解释)如下：

alt text

我喜欢它因为：

很简单：您可以从图片中获取它。
它运作良好(并且可扩展)，而没有太多的合并和冲突问题。
您可以随时(出于敏捷的精神)发布"工作软件"。

并且，以防万一它不够明确：开发是在"工作分支"中完成的，干线用于DONE(可释放)代码。有关所有详细信息，请检查多个敏捷团队的版本控制。

Divmod的终极质量开发系统是保持中继线稳定并在分支机构中完成所有工作的开发过程的一个很好的参考。快速总结：

完成的所有工作都必须具有相关的票证
为每个故障单创建一个新的分支，完成该故障单的工作
来自该分支的更改不会重新合并到主干干线中，而无需其他项目成员的审查。

他们为此使用SVN，但是可以使用任何分布式版本控制系统轻松完成此操作。

我认为您的第二种方法(例如，考虑到主干的稳定性)，例如，对发布进行标记并在分支中进行实验性工作)是最好的方法。

应当清楚的是，分支机构在分支机构的时间点继承了系统的所有错误：如果将修补程序应用于主干，则如果您将分支机构维护为某种形式，则必须逐一遍历所有分支机构。释放周期终止符。如果您已经拥有20个发行版，并且发现了可以追溯到第一个版本的错误，则必须重新应用此修复程序20次。

分支应该是真正的沙箱，尽管树干也必须扮演这个角色：标签将指示该时间点代码是否为"黄金"，适合发布。

除非更改过于重大，不稳定或我们即将推出其中一种产品，否则我们将在主干上进行开发，在这种情况下，我们将创建一个临时分支。我们还为每个单独的产品版本创建一个永久分支。我发现Microsoft的《分支指导》文档很有帮助。埃里克·辛克(Eric Sink)的分支教程也很有趣，并指出，对于Microsoft而言，对我们中的某些人来说可能过于沉重。就我们而言，我们实际上使用了Eric的团队所说的方法。

这取决于您的情况。我们使用Perforce，通常会有几条开发线。主干被认为是"黄金"，所有开发都发生在分支机构，只要它们足够稳定可以集成，它们就会合并回到主线。这样就可以拒绝那些无法完成的功能，并且可以随着时间的推移提供可靠的增量功能，以便独立项目/功能可以使用。

合并和追赶引入后备箱中的新功能会产生集成成本，但是无论如何您都会遭受这种痛苦。每个人都在主干上共同发展会导致荒唐的西部局势，而分支机构则使您可以扩展规模并选择要采取苦涩整合方案的地步。目前，我们的规模已扩展到十几个项目的一百多个开发人员，每个项目使用相同的核心组件发布多个版本，并且运行良好。

这样做的好处是您可以递归执行此操作：大功能分支可以是其自己的主干，其他分支也可以退出。此外，最终版本会获得一个新分支，为您提供进行稳定维护的地方。

尝试根据新开发来管理当前生产代码的维护充其量是有问题的。为了减轻这些问题，一旦完成测试工作并且准备好交付代码，则代码应分支到维护行中。此外，主线应分支以协助稳定发行，包含实验性开发工作或容纳其生命周期跨越多个发行版的任何开发工作。

仅当代码之间存在冲突(或确定性)而很难以任何其他方式管理时，才应创建非维护分支。如果分支机构不能解决后勤问题，它将创建一个。

正常发布开发发生在主线中。开发人员签入和签出主线以进行正常发布工作。当前生产代码补丁的开发工作应该在该版本的分支中，一旦补丁通过测试并部署，便与主线合并。非维护部门的工作应根据具体情况进行协调。

这取决于您的开发工作量。多个并行工作的团队将无法在同一代码(全部)上有效地工作。如果您只有一小部分人在工作，而您的主要关注点是削减分支机构，那么您可以继续工作，同时返回分支机构，以对当前有效的生产代码进行错误修复。这是分支的琐碎用途，并且不太麻烦。

如果您有很多并行开发，则需要为每个工作都创建分支，但这还需要更多的纪律：确保分支经过测试并准备好合并。计划合并，因此两个组不会尝试同时合并等。

某些分支的开发已经持续了很长时间，您必须允许从主干到分支的合并，以减少最终合并回主干时的意外情况。

如果您有大量的开发人员，则必须进行试验，并对自己所处的环境有个感觉。这是Microsoft的页面，可能会有些用处：http://msdn.microsoft.com/zh-cn/library/aa730834(VS.80).aspx

我们使用主干进行主要开发，并使用分支进行发布维护工作。很好用但是分支应该只用于错误修复，而不能进行重大更改，尤其是在数据库方面，我们有一个规则，即只能在主干上进行模式更改，而不能在分支中进行更改。

我们遵循主干=当前的开发流，分支=版本的方法。在向客户发布时，我们会分支树干，并保持树干向前滚动。您需要决定要准备支持多少个版本。您支持的越多，您将在错误修复方面进行的合并就越多。我们尝试让客户在主干之后最多发布2个版本。 (例如Dev = 1.3，受支持的版本1.2和1.1)。

如果您要经历发布周期的重大功能，那么您将陷入困境。否则，我们将在主干中工作，并在构建时针对每个生产版本进行分支。

先前的生产版本当时已移至old_production_，而当前的产品发布始终只是生产。我们所有的构建服务器都知道生产是如何部署生产分支，并且我们通过强制触发器来开始构建。

这实际上取决于您的组织/团队对版本的管理程度以及所使用的SCM。

如果可以轻松计划下一步(在下一发行版中)，那么最好在主干中进行开发。管理分支机构需要更多时间和资源。但是，如果不能轻易地计划下一个计划(在大型组织中一直都在发生)，您可能最终会选择樱桃采摘(数百/千)而不是分支(数或数十)。
使用Git或Mercurial，管理分支比cvs和Subversion容易得多。我会选择稳定的主干/主题分支方法。这就是git.git团队使用的。阅读：http：//www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
通过Subversion，我首先应用了开发中的方法。关于发布日期，有很多工作要做，因为每次我不得不挑选提交时(我的公司不擅长计划)。现在，我是Subversion的专家，并且对Subversion中的分支管理非常了解，因此我正在朝着稳定的主干/主题分支方法发展。它的工作比以前好得多。现在，我正在尝试git.git团队的工作方式，尽管我们可能会坚持使用Subversion。

这是我更喜欢的SVN设计：

根
- 发展
  - 分行
    - 功能1
    - 功能2
    - ...
  - 树干
- 贝塔
  - 标签
  - 树干
- 发布
  - 标签
  - 树干

除了需要自己分支的主要功能以外，所有工作都是通过开发/主体完成的。在针对开发/树干测试工作之后，我们将经过测试的问题合并到Beta /树干中。如有必要，将针对Beta服务器测试代码。当我们准备好进行一些更改时，我们只需将适当的修订合并到发行版/主体中并进行部署。

可以在beta分支或release分支中进行标记，因此我们可以跟踪beta和release的特定版本。

这种设计具有很大的灵活性。如果某些修订未通过Beta中的测试，这也使我们很容易将Beta / trunk中的修订保留下来，而将其他修订合并为release / trunk。

对我来说，这取决于我使用的软件。

在CVS下，我只会工作在" trunk"中，而不会标记/分支，因为否则确实很痛苦。

在SVN中，我将在中继中执行"出血边缘"操作，但是当需要进行服务器推送时，将对其进行适当标记。

我最近切换到git。现在我发现我从不在后备箱里工作。相反，我使用一个名为" new-featurename"的沙箱分支，然后合并到一个固定的"当前生产"分支中。现在，我考虑了一下，在合并回"当前生产版本"之前，我确实应该先创建" release-VERSIONNUMBER"分支，以便可以回到较早的稳定版本...

通常，主干应该是您的主要开发源。否则，您将花费大量时间合并新功能。我已经看到它以另一种方式完成，并且通常会导致很多最后一刻的集成难题。

我们将发布的产品贴上标签，以便我们能够快速应对生产紧急情况，而又不会分散积极的开发。

树干通常是主要的开发线。

发布是分支的，通常是在分支上进行实验或主要工作，然后在准备与主开发线集成时合并回主干。

我们使用的方法是Perforce方法，Laura Wingerd的著作中对此进行了详尽的讨论：

http://oreilly.com/catalog/9780596101855/index.html

尽管本书以perforce为中心(Wingerd是Perforce产品经理)，但是这些概念可以应用于任何或所有VCS。

perforce方法(和平台)为我们提供了很好的服务。许多公司(谷歌，Intuit和我听说过，Microsoft Windows本身)都使用它。

这本书非常值得一读。

阅读此：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

颠覆惯例问题恕我直言，没有一个万能的答案。

这实际上取决于项目和使用它的公司的动态。在快节奏的环境中，当发行可能每隔几天发生一次时，如果您尝试认真地标记和分支，最终将导致无法管理的存储库。在这样的环境中，需要时分支的方法将创建一个更加可维护的环境。