开发中的分支管理

一、前言

在软件开发过程中，分支管理是软件开发中不可或缺的一部分，它不仅关乎代码的组织和版本控制，更是提高团队协作效率、保障代码质量和加速产品迭代的关键。具体体现在以下几个方面：

• 并行开发：分支允许团队成员在同一代码库上同时开发不同功能或修复不同的问题，而不会相互干扰。这大大加速了开发进程，使得多个特性可以并行推进。
• 隔离变更：通过在单独的分支上工作，可以将新功能开发、bug修复或其他实验性更改与主干代码隔离开来。这有助于保持主分支的稳定性和可预测性，确保生产环境的代码始终处于可靠状态。
• 代码质量和审查：分支管理促进了代码审查文化，因为在合并到主分支之前，团队成员可以审查彼此的工作。这有助于发现潜在的错误、设计缺陷和不符合编码规范的地方，从而提升代码质量。
• 风险管理：在特性分支上工作可以视为一种风险控制机制。如果某个新功能开发遇到问题或决定放弃，可以直接丢弃或重做该分支，而不影响其他开发工作或生产环境。
• 版本控制和回滚：通过分支管理，可以轻松追踪和回滚到任何特定版本。这对于快速应对生产问题、撤销错误的更改或分析历史变更非常有用。
• 协作和沟通：清晰的分支命名规则和合并流程有助于团队成员理解项目状态和各自的责任，减少沟通成本。分支历史记录也是团队协作的宝贵信息来源。
• 持续集成/持续部署(CI/CD)：分支管理与CI/CD流程紧密集成，允许自动化测试和部署基于特定分支的代码，确保每次合并都是经过验证的，符合部署标准。

二、分支管理

通常情况下，Git的远程分支如 main 或 master (代表主分支)和 test 会默认设置为只读的，这是为了防止为了保护分支的稳定性和质量，许多Git托管服务提供了保护分支的功能。这种保护可以包括禁止直接推送（push）到这些分支，要求所有更改必须通过拉取请求（Pull Request）进行，从而实现代码审查。这给予团队一个检查和批准过程，确保只有经过评审和测试的代码才能合并到只读分支。

现在，分别有两个只读分支，为 master 和 dev 分支。master 作为线上分支，dev 作为开发和测试分支。分支管理的流程大致如下：

• 基于 dev 分支新建一个开发分支 dev_lyl_示例_20240512，然后用于开发代码。
• 开发完成后，将分支 dev_lyl_示例_20240512 的代码提交到远程仓库。
• 在远程仓库中把 dev_lyl_示例_20240512 分支的代码合并到 dev 用于测试环境部署。
• 基于master分支新建一个分支 master_lyl_示例_20240512 ，用于提交到生成环境的分支。
• 将需要发布到生产环境的代码放入 master_lyl_示例_20240512 分支，提交到远程仓库。
• 在远程仓库中把 master_lyl_示例_20240512 分支的代码合并到 master 用于生成环境部署。

为什么不直接在远程仓库中将 dev 分支的代码合并到 master ?

因为在实际环境中，dev 分支代码和 master 分支代码可能存在部分差异，采用这种方式可以将只需要发布的代码提交到生产环境，从而确保了生产环境代码是无污染的。

三、分支间代码同步

当我们把 dev_lyl_示例_20240512 开发的代码合并到 dev 成功部署测试无误后，这个时候就需要将这部分代码同步到 master_lyl_示例_20240512 分支。在IntelliJ IDEA中，比较常用的方法有三种。

• 摘取法：

  该方法适用于将某一次的改变全部体现在本分支上。
  

• 比对法一：

  该方法适用于需要同步的代码在该分支上存在，但存在差异。
  
  
  

• 比对法二：

  该方法是在比对法一的基础上，加上了同步当前分支不存在的类的方式。