分支策略
分支策略
您组织和合并 Git 分支的方式称为 分支策略。对于许多团队来说，最简单的方法是明智且有效的：
- 在功能分支中进行更改。
- 将功能分支直接合并到 main。
然而，如果您的团队有复杂的需求（例如测试和合规要求），您可能需要考虑不同的分支策略。
我们希望揭开一些更常见的策略的神秘面纱。并非每个人的团队中都有 Git（或版本控制）专家。如果您知道您的团队正在 Git 技能的边缘工作，那么这些信息适合您。
当您使用极狐 GitLab 替换多个不同的工具时，您做出的有关 Git 分支策略的决策很重要。通过仔细的计划，您可以建立以下之间的清晰连接：
- 您收到的初始错误报告。
- 您的团队进行的提交以修复这些错误。
- 将这些修复程序向后移植到其他版本或客户的过程。
- 使您的修复程序对用户可用的部署。
仔细选择有助于您充分利用极狐 GitLab 中的单一数据存储。
我需要更复杂的 Git 分支策略吗？
如果出现以下情况，您可能已经超越了当前的 Git 分支策略：
- 您使用持续交付。
- 您有大量自动化测试。
- 您必须为一个客户修复关键错误而不影响其他客户。
- 您维护多个历史版本的产品。
- 您的产品没有单一的生产分支，因为它支持多个操作系统或平台。
- 您的产品对于每个版本有不同的部署或认证要求。
不要实施比您的产品需要更复杂的策略。
何时将项目拆分为多个存储库
您应该维护一个具有复杂分支结构的 Git 存储库，还是将项目拆分到多个存储库中？没有单一正确答案。这取决于您是否有人员和专业知识来支持。
极狐 GitLab 提供了假设您的存储库用于单个产品的自动化，尽管该产品可能包含多个版本。要确定您应该有多个存储库还是一个复杂的存储库，请问这些问题：
- 是同一产品吗？
- 所有元素都使用相同的构建过程吗？
- 底层代码相似或相同吗？
无论您选择什么（无论是复杂的单一存储库还是一组较小的存储库），您都应该预期会花费工程时间进行维护。确定您准备进行哪种类型的工程工作：
- 如果您在单个存储库中维护多个产品的代码，请计划稍后进行自定义工作以使用极狐 GitLab 的所有功能。
- 在多个存储库之间合并工作比在同一存储库中的分支之间合并复杂。计划工程时间以构建自定义发布过程并管理跨存储库的代码流。
主要分支策略类型
分支和代码管理策略取决于您的产品需求。没有预先存在的策略可以涵盖所有，但我们已经确定了一些主要类别：
Webservices
此策略遵循标准的 Git 实践。main 分支是您的生产分支，非常适合单个 Webservices：有一个规范的生产版本，并且不支持先前的修订版本。
对于此配置，git-flow可能适合您。它是标准化的，您不必维护任何东西。
在这个例子中，feature-1 直接从 main 分支出来。完成后，feature-1 直接合并回 main。此合并提交用方框突出显示。长期存在的分支，如 feature-2，可能会定期合并来自 main 的最新更新作为开发的一部分。完成后，feature-2 合并到 main 中，并发布 1.1：
Rendering chart...
长期存在的发布分支
如果您的产品有必须长期与 main 分支分开的分支，此分支策略是合适的。一些示例包括：
- 同一软件包的多个生产版本。例如：一个当前版本和遗留版本。当前版本接收功能更新和热修复，而以前的版本仅接收热修复和安全发布。
- 当前生产版本和长期存在的测试版。当主要软件依赖项（如软件开发工具包或 SDK）引入破坏性更改时，您可能需要采用此方法。当前生产版本接收功能更新和热修复。测试版接收这些功能更新和热修复，同时您的团队还在构建对即将到来的 SDK 更改的支持。
如果您打算锁定一个长期存在的分支，定义和执行您的热修复过程是至关重要的。如果没有定义和执行，每个更改都将成为热修复。
在这个例子中，2.0 分支是从 main 的 1.0 发布提交中创建的。功能从 2.0 分支出来，并合并回 2.0。同时，任何热修复分支都基于 main 的最新发布（1.0），并合并回 main 作为发布 1.1。然后 2.0 分支将 1.1 发布的更改合并进来，并将其作为 2.0 的开发的一部分。添加另一个功能（feature-2）后，2.0 分支准备投入生产。它合并到 main 中，并发布 2.0：
Rendering chart...
从 SVN 分支策略迁移
从 SVN 迁移到 Git 的遗留项目应审查其分支方法。在 Git 中的一些 SVN 中心分支方法可能会阻止您充分利用极狐 GitLab。需要重新审视的一些工作流：
- 您从 main 创建一个长期存在的分支（如 1.0），然后锁定 1.0 分支以阻止任何未经预先批准的热修复的更改。
- Git 比 SVN 更好地处理合并冲突。
- 除非您有合同义务使用它们，否则避免创建长期存在的分支。虽然 Git 处理冲突很好，但长期存在的分支需要您花时间将修复合并到多个分支。
- 因为您的产品不支持功能标志，所以您使用分支。
每个环境一个分支
此分支策略对于拥有多个由不同团队构建的相互依赖服务的组织来说很常见。它通常与瀑布或 V 型开发过程一起使用。
在这个例子中，被标记为 v1.1 RC1 的提交被标识为版本 1.1 的发布候选。功能继续从 main 分支出来并返回到 main，而发布候选提交在 test 和 UAT 环境中进行了测试。此过程针对每个被视为发布的提交重复进行：
Rendering chart...