分支

什么是分支？

在开发中，分支涉及对一组原始程序或对象进行拆分和修改，以实现并行工作。这允许开发人员在保留初始副本的同时，对每个分支进行各种修改。在此上下文中，每个修改后的副本被称为分支，而原始程序被称为主干、基线、主线或主分支。

分支的概念是版本控制和软件管理的基础，因为它在建立代码稳定性方面起着至关重要的作用。通过创建独立的分支，开发人员可以修复现有版本中的错误、集成新功能，并在独立测试后引入新版本。这种方法提供了一种系统化和有组织的方式来管理变更，并确保软件的整体稳定性和完整性。

它还可以实现分块，即不同的团队可以同时处理程序的不同部分。每个团队都拥有一个版本的副本，并且团队专门致力于处理此副本。在多个分支持续变更的情况下，正在为下一个版本开发的分支称为开发分支。

分支可以与“fork”（分叉）互换使用，但两者之间存在一些差异。在 forking 中，开源软件的特定软件程序的源代码被用来创建一个新程序，而新程序被称为 fork。

什么是主干

它是从主干中复制或分支以提供给消费者的基础程序。它也被称为主通道或主通道，或简称为一条线。分支通常由版本控制软件（VCS）处理，它将已开发和正在测试的代码与已稳定和经过测试的代码分开。

什么是合并

合并被定义为使用其他分支上进行的更改来更新任何分支，并将更改放置在主干（或也称为基线）上的行为。虽然分支允许团队并行工作，但所有分支都链接到主干。

因此，分支支持并行工作流，但所有分支仍然连接到主干。为了在分支中体验主干的变化，合并会在一段时间间隔后发生。这种做法消除了由不同代码集引入的编码密度和不一致的风险。这两个步骤发生在代码合并时；因此，尽早频繁地合并比出现导致代码更改的合并冲突要好。

有哪些不同的分支策略

分支策略是指全球各业务组织在制定和执行战略计划时所采用的各种方法。

1. 功能分支
   任务 = “用户故事”，或者有些人称之为功能，是在称为功能分支模型的分支下开发的。这种特定的计划有助于开发团队发布代码的特定部分，从而将版本分段，而不是形成一个需要大量测试和审查时间的庞大版本。但有一个潜在的缺点——开发人员可能会在一个特定的代码段上工作很长时间，然后他们才能将更改合并回中央存储库，这可能会创建长时间运行的分支，从而导致合并回基线代码时耗时。
2. 发布分支
   在发布分支中，为在发布周期内可能完成的所有可能任务和功能开发一个新分支。此策略特别适用于在主干中进行开发的项目，并且随着时间的推移存在多个发布版本和补丁版本，因为它允许团队在给定的发布中处理特定主干的各种功能。主要发布可以合并来自功能分支的更改或功能分支中的新功能，而次要补丁直接在发布分支上进行处理。缺点是当来自多个分支的发布以及其他人的贡献时，代码会变得脆弱。
3. 热修复分支
   存在许多用于快速修复生产环境中严重问题的分支，称为热修复分支。这些是从主干或发布分支派生的较新分支，用于解决关键错误，并在修复完成后，将更改集成回主干和与修复相关的其他分支。

分支的优点

同样，可以强调与分支相关的以下主要优点

分支提供了许多好处，包括

1. 并行开发：这意味着多个团队可以并行处理不同的功能或任务，从而更快地交付产品。
2. 快速反馈：众包的好处之一是可以在短时间内向开发人员提供反馈，从而可以更快地纠正某些问题。
3. 结构化发布：它在计划的环境和发布周期中使用时非常有效，可以增强开发管理。
4. 增强协作：它使正在处理公共基线的不同开发团队能够更轻松、更有条理地实施更改。

流行的分支工具

1. Git
   
   • 轻量级分支
     目前，Git 在其轻量级分支系统方面是独一无二的，这使其区别于一些竞争方法。在 Git 中，创建分支、删除分支和合并分支等操作都易于完成，因为 Git 分支只是指向提交的指针。这不仅使开发人员能够尝试新概念、在两个上下文之间切换，或者在有限的时间内并发地处理系统中的不同区域。
   • 分布式版本控制
     这是一个分布式版本控制系统（DVCS），其中每个开发人员都在自己的设备上使用完整的存储库历史记录。它改进了协作方式，因为开发人员最初会在本地贡献和进行更改，然后再将更改推送到其他存储库。它也使版本控制系统更加可靠，因为一个中央服务器可能会丢失，但数据仍然是安全的。
   
   各种分支策略的实现
   Git 支持多种分支策略，例如
   
   1. 功能分支：他们在一个中心化的源代码版本上工作，并为每个功能或任务创建新文件夹/分支，以将其分开并避免干扰。
   2. 发布分支：为每次发布创建新分支，因为这样可以同时修补多个版本，而不是一个版本。
   3. 热修复分支：它们是在主干或发布分支的子分支上完成的，完成后，更改将被合并。
   4. 主干开发：开发人员直接在主干上进行开发，对于某些小型项目或快速实验，他们使用临时创建的分支。
2. SVN (Subversion)
   分支方法
   SVN 依赖于中央存储库，并作为一个集中式版本控制系统（CVCS）工作。在 Subversion 中，分支是通过对存储库的项目路径执行复制并在通常命名为 /branches 的子文件夹中进行的。这种复制操作很简单，但不如 Git 的分支系统易于管理，这可能会导致大型存储库的性能受限。
   与 Git 的区别
   
   • 集中式 vs. 分布式：Subversion 的结构是集中式的，涉及使用单个存储库来存储代码：开发人员需要网络连接才能提交更改。在某种程度上，这是正确的，因为 Git 是一个分布式模型系统，允许用户进行本地提交并离线工作。
   • 分支与合并：SVN 分支效率低于 Git，并且合并有时可能很复杂，因为主要依赖于服务器端活动。Git 工具中的终端操作，合并操作，设计得非常快速高效。
   • 提交历史：SVN 提供清晰的线性提交历史，而 Git 则更自由，提供分支、合并，因此是非线性历史。
3. Mercurial
   分支与合并功能
   有许多不同的版本控制系统，其中以下两个最受欢迎：Mercurial 和 Git。它提供了许多功能来实现有效的分支和合并。
   
   • 命名分支：Mercurial 支持所谓的命名分支，这些分支都是完全可提交和可共享的。每个提交都可以关联到一个或多个分支，这样可以更容易地查看在一个分支上进行的更改并将其与另一个分支进行比较。
   • 书签：Mercurial 也有类似轻量级分支的概念，称为书签，它们实际上是指向特定更改集（就像 Git 中的分支一样）的指针。它们最适合短期分支和基于功能的流程。
   • 合并：Mercurial 设计了其合并方式和命令，使开发人员能够合并来自不同分支的差异。它还提供了解决在文件集成过程中可能出现的合并冲突的方案。

Git、SVN 和 Mercurial 之间分支模型的区别

1. Git
   
   • 优点：灵活的线性结构、快速轻量的分支、强大的合并功能、可以离线或分布式工作，并且可以非常灵活地设置。
   • 用例：最适合有大量分支、测试和原型制作的项目，以及在线完成所有工作的场景。
2. SVN
   
   • 优点：也称为分层或分级模型，它是一个实用的模型，适用于希望拥有单一控制中心和访问点的环境。
   • 挑战：与分布式系统相比，不同的分支和合并策略效率较低，提交需要网络访问。
   • 用例：当应用于具有一个主要共享点且使用团队仅限于在连接环境中工作的项目时最有效。
3. Mercurial
   
   • 优点：Arena 版本控制系统中的极其灵活的分支和书签专为分支和合并操作而设计。
   • 挑战：使用 SVN 的组织数量较少，这意味着第三方工具和集成应用程序的市场较小。
   • 用例：仅适用于具有严格分支模型的分布式开发，并且如果团队是 Mercurial 开发过程的一部分。

通过这一点，可以证明通过熟悉 Git 的架构和功能，SVN、Git 和 Mercurial 的优缺点以及分支策略，开发团队将能够为他们特定的活动和需求选择最有效的版本控制工具和分支模型。

结论

分支对于软件开发至关重要，它允许许多开发人员同时处理改进的功能或新元素，同时修复错误或在主代码行（或主干）中执行特定任务。该模型包含各种策略，包括；功能分支、发布分支以及热修复分支，每种策略都有其自身在开发中的需求。

Git 提供了许多功能，例如使用轻量级分支的能力、用于版本控制的分布式系统以及支持多种分支模型。因此，它适用于快速变化的协作开发环境。SVN 针对简单性和围绕中央存储库的集成进行了优化，并包含分支和合并的概念。虽然基本健全且复杂度较低，但效率较低，但非常适合受控、依赖网络的项目。Mercurial 对于集中式版本控制系统来说是自给自足的，它成功地融合了分支和合并，这些被称为命名分支和书签。

当开发团队理解了这些工具和技术后，它们有助于促进更轻松的协作，并以更结构化、更有效的方式进行编码和管理工作，贯穿开发和发布周期。