Jay 的博客

主题

分支管理 ​

分支管理在软件开发过程中占据着举足轻重的地位，它是工程化思想在代码管理领域的重要体现。它标志着我们从以往那种随意、混乱、无序且无法追溯的代码管理方式中解脱出来，转而采用科学的理论和方法对代码进行有序管理。高效的分支管理不仅是团队协作的坚实基础，还是确保代码质量、推动功能迭代以及快速错误修复的关键所在。

分支管理的优点 ​

  1. 提高团队协作效率：

    • 分支管理允许开发团队并行工作，每个成员可以在自己的分支上独立开发功能或修复错误，而不会相互干扰。
    • 通过分支合并，团队成员可以轻松地集成各自的工作成果，确保代码库的统一性和一致性。

  2. 保障代码质量：

    • 分支管理使得代码审查（Code Review）变得更为容易和高效。开发者可以在提交代码之前，通过分支进行详细的审查，确保代码的质量。
    • 独立的分支也便于进行单元测试、集成测试和回归测试，从而及时发现并修复潜在的问题。

  3. 支持持续集成和持续部署（CI/CD）：

    • 分支管理为 CI/CD 流程提供了基础。每个分支都可以配置独立的自动化构建、测试和部署流程，确保在代码合并到主分支之前，已经经过了充分的验证。合并后的代码及时的进行部署，从而实现快速迭代和持续改进。

  4. 实现灵活的功能迭代：

    • 分支管理使得开发团队可以灵活地添加、修改或删除功能。每个功能或修复都可以在一个独立的分支上进行开发和测试，而不会影响到其他功能的开发进度。有助于团队快速响应市场变化或用户反馈，及时调整产品策略。

  5. 简化错误追踪和修复：

    • 在分支管理中，每个分支都记录了相关的开发历史、提交记录和变更说明。这使得在出现错误时，能够迅速定位到问题的源头，并采取相应的修复措施。
    • 分支管理还使得回滚到之前的稳定版本变得简单快捷，降低了因错误代码导致的潜在风险。

  6. 增强版本控制和发布管理：

    • 分支管理为版本控制提供了强有力的支持。通过创建和维护不同的分支（如主分支、开发分支、发布分支等），团队可以清晰地管理不同版本的代码和发布计划。

成熟的分支管理策略 ​

市面上已经有一些成熟的分支管理策略，如 Git Flow、GitHub Flow 和 GitLab Flow 等。这些策略提供了一套完整的分支管理框架，帮助团队更好地进行代码管理。下面是这些策略的简要介绍：

Git Flow ​

Git Flow 是一种广泛使用的分支管理策略，它定义了多种分支类型，以支持不同阶段的软件开发工作。Git Flow 的核心分支包括：

  1. 主分支（Master/Main）：主分支是代码库的稳定版本，通常用于生产环境。它只接受来自发布分支的合并，并且每次合并都会进行严格的代码审查和测试。
  2. 开发分支（Develop）：开发分支是日常开发的主要分支，包含了最新的功能和修复。它从主分支分出，并最终合并回主分支。开发分支可以接受来自功能分支和修复分支的合并。
  3. 功能分支（Feature Branch）：功能分支用于开发新的功能。每个功能都有一个独立的功能分支，从开发分支分出，并在功能开发完成后合并回开发分支。
  4. 修复分支（Hotfix Branch）：修复分支用于紧急修复生产环境中的错误。每个修复都有一个独立的修复分支，从主分支分出，并在修复完成后合并回主分支和开发分支。
  5. 发布分支（Release Branch）：发布分支用于准备新的版本发布。每个版本都有一个独立的发布分支，从开发分支分出，并在发布完成后合并回主分支和开发分支。发布分支创建后只允许进行必要的修复和文档更新，不允许添加新功能。

Git Flow 的分支管理策略具有以下优点：

  • 清晰的分支结构：Git Flow 定义了明确的分支类型和用途，使得团队成员能够清晰地了解每个分支的作用和生命周期。
  • 灵活的功能迭代：功能分支允许团队成员独立开发新功能，而不会影响到其他功能的开发进度。
  • 高效的错误修复：修复分支使得开发团队能够快速响应生产环境中的错误，并确保修复能够及时合并回主分支和开发分支。
  • 稳定的版本发布：发布分支使得团队可以有条不紊地准备新版本的发布，并在发布完成后将代码合并回主分支和开发分支。
  • 易于回滚和恢复：Git Flow 的分支结构使得在出现问题时，可以轻松地回滚到之前的稳定版本，或者恢复到某个特定的功能或修复。

然而，Git Flow 也有一些缺点：

  • 分支数量较多：Git Flow 定义了多种分支类型，每个分支都有特定的用途。这可能会导致分支数量较多，增加了分支管理的复杂度。
  • 分支合并频繁：Git Flow 要求在各个分支之间频繁地进行合并操作，这可能会增加代码冲突的风险。
  • 维护成本：维护多个分支和标签需要额外的工作量，特别是在项目规模较大时。这可能导致项目进展缓慢或资源分配不均。

适用场景：

  • 项目规模较大，需要明确的分支管理和协作流程来确保项目的顺利进行。
  • 团队成员较多，需要一种结构化的分支管理策略来协调不同团队成员之间的工作。
  • 多版本维护：项目需要同时维护多个版本，例如支持旧版本的 bug 修复和新版本的开发。

GitHub Flow ​

GitHub Flow 是一种轻量级的分支管理策略，它简化了分支结构，使得开发团队能够更加高效地协作。GitHub Flow 的核心分支包括：

  1. 主分支（Master/Main）：主分支是代码库的稳定版本，通常用于生产环境。它只接受来自功能分支的合并，并且每次合并都会进行严格的代码审查和测试。
  2. 功能分支（Feature Branch）：功能分支用于开发新的功能。每个功能都有一个独立的功能分支，从主分支分出，并在功能开发完成后合并回主分支。

GitHub Flow 的分支管理策略具有以下优点：

  • 简洁的分支结构：GitHub Flow 只定义了两种分支类型，使得分支管理变得简单明了。
  • 灵活的功能迭代：功能分支允许团队成员独立开发新功能，而不会影响到其他功能的开发进度。
  • 快速的版本发布：主分支作为稳定版本，可以随时进行发布。团队成员只需将功能分支合并回主分支，即可完成版本发布。

然而，GitHub Flow 也有一些缺点：

  • 合并到主分支的错误将直接影响生产环境：由于 GitHub Flow 强调持续交付和部署，一旦合并到主分支的代码存在错误，这些错误将很快被部署到生产环境。这可能会导致生产环境的不稳定或中断，对用户体验造成负面影响。
  • 不太适合多个开发人员并行开发复杂功能：在 GitHub Flow 中，每个功能或修复通常都创建在单独的功能分支上。当多个开发人员需要并行开发复杂功能时，可能会导致分支数量激增，分支管理变得复杂。

适用场景：

  • 小型项目：项目规模较小，功能模块较少，或者团队较小。
  • 持续部署：产品需要频繁更新，可能每天都有新的部署。
  • 简单的发布流程：发布流程简单，不需要复杂的测试和多环境部署。

GitLab Flow ​

GitLab Flow 是一种结合了 Git Flow 和 GitHub Flow 的分支管理策略，它结合了两种策略的优点，并引入了一些新的概念和规则。GitLab Flow 可以说是全盘采纳了 GitHub Flow，然后吸收 Git Flow 优点对 GitHub Flow 进行修补。

Gitlab Flow 的采用”上游优先”（upsteam first）原则，即只存在一个主分支(master/main)，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。

此外，Gitlab Flow 还为不同环境创建了对应的环境分支。环境分支基于主分支或者上游分支创建而来。比如，”开发环境”的分支是 master，”预发环境”的分支是 pre-production，”生产环境”的分支是 production。

GitLab Flow 的核心分支包括：

  1. 主分支（Master/Main）：主分支用于存在最新的稳定版本代码，是所有分支的上游。其作用类似于 GitHub Flow 的主分支。合并到主分支的代码需进行严格代码评审（Merge Request，简称 MR）和自动化测试。
  2. 功能分支（Feature Branch）：功能分支用于开发新的功能或修复缺陷。每个功能都有一个独立的功能分支，从主分支分出，并在功能开发完成后合并回主分支然后删除。（注意，Git Flow 的热修复分支被合并到功能分支中了。）
  3. 环境分支：对应具体的发布环境，基于主分支创建。用于测试、预发布等阶段。最终合并回主分支后删除。如果环境间存在上下游的关系，则代码只能从上游环境留向下游环境（如，测试环境->预发环境->生产环境）。
  4. 发布分支：用于维护特定版本，从主分支特定点拉出。发布分支是常驻分支，用于长期支持特定版本或进行补丁修复。发布分支只会合并严重的漏洞修复更新。 尽可能先将漏洞修复的更新合并到 main，然后拣选（cherry-pick）到发布分支。

Gitlab Flow 的分支管理策略具有以下优点：

  • 清晰的分支结构：相对于 Git Flow，GitLab Flow 的分支管理更加简化，减少了管理开销。但又不像 GitHub Flow 那样过分简化。Gitlab Flow 任保留了明确的分支类型和用途，使得团队成员能够清晰地了解每个分支的作用和生命周期。
  • 灵活的功能迭代：功能分支允许团队成员独立开发新功能，而不会影响到其他功能的开发进度。
  • 稳定的版本发布：发布分支使得团队可以有条不紊地准备新版本的发布。
  • 易于回滚和恢复：GitLab Flow 的分支结构使得在出现问题时，可以轻松地回滚到之前的稳定版本，或者恢复到某个特定的功能或修复。
  • 灵活的分支扩展：GitLab Flow 支持根据项目需求灵活扩展分支类型和数量，例如根据环境来创建分支。

然而，Gitlab Flow 也有一些缺点：

  • 分支数量较多：尽管相对于 Git Flow 做了精简， GitLab Flow 任定义了多种分支类型，每个分支都有特定的用途。这可能会导致分支数量较多，增加了分支管理的复杂度。

适用场景：

  • 中小型项目：项目规模适中，功能模块较少，或者团队规模较小。
  • 团队成员较多，需要一种结构化的分支管理策略来协调不同团队成员之间的工作。
  • 多版本维护：项目需要同时维护多个版本，例如支持旧版本的 bug 修复和新版本的开发。

制定适合团队的分支管理策略 ​

在制定分支管理策略时，可以参考已有的成熟方案，并实际考量团队情况。可以完成参照已有的成熟方案；也可以基于已有的成熟方案进行调整，因地制宜，使之更加符合团队需求。

可以从几个方面考量：

  1. 团队规模和开发流程：根据团队规模和开发流程，选择适合的分支管理策略。例如，对于小型团队，可以使用 GitHub Flow；对于大型团队，可以使用 Git Flow。
  2. 项目需求：根据项目的需求，确定需要使用的分支类型和数量。例如，如果项目需要频繁发布新版本，可以考虑增加发布分支的数量。
  3. 分支生命周期：根据项目的需求，确定每个分支的生命周期。例如，功能分支的生命周期较短，而发布分支的生命周期较长。
  4. 代码审查和测试：在分支合并时，需要进行代码审查和测试，以确保代码的质量和稳定性。根据项目的需求，确定代码审查和测试的流程和规则。
  5. 分支命名规范：为了便于团队成员理解和协作，需要制定统一的分支命名规范。例如，功能分支的命名可以遵循 feature/ 前缀，修复分支的命名可以遵循 hotfix/ 前缀。
  6. 分支管理工具：选择合适的分支管理工具，如 GitLab、GitHub 等，以支持分支管理策略的实施。

总之，制定分支管理策略需要根据团队规模、项目需求和开发流程等因素进行综合考虑，并灵活调整。同时，还需要制定分支命名规范和代码审查规则，以确保分支管理策略的实施。

关于代码审查（Code Review）

尽管代码审查在分支管理中并不是不可或缺的一环。但其对于保证主分支代码稳定，确保代码质量，提高代码的可读性和可维护性非常重要且有效的。如果你的团队有能力去执行代码审查，那么强烈建议将代码审查纳入 SOP 中。

代码审查一般穿插在分支合并过程中进行。主要是在代码合并到主分支的时候进行代码审查。Git Flow 是在热修复分支和功能分支合并到主分支时进行代码审。GitHub Flow 和 GitLab Flow 则是在功能分支合并到主分支时进行代码审。

此外，代码审查分为人工审查和自动化审查。人工审查主要关注代码逻辑、代码风格、代码可读性等方面。自动化审查主要关注代码质量、代码风格等方面。

参考文献 ​