Git 分支合并中的陷阱与应对之道

前端

2023-10-26 05:39:24

在一个团队合作项目中，Git 分支管理是不可或缺的重要实践。然而，当多位开发者同时在不同分支上工作时，合并操作就成为了一项既有必要又极具风险的任务。本文将详细讲述一次由 Git 分支合并引起的真实问题，以及如何有效地解决该问题。

在一次项目开发过程中，我们采用了 AoneFlow 的分支管理模式，其中包含四种主要分支类型：主干分支 (master)、特性分支 (feature)、发布分支 (release) 和开发分支 (develop/test)。

当新需求出现时，我们会从主干分支创建特性分支来进行开发。开发完成后，我们会将特性分支合并回开发分支，再从开发分支合并到发布分支，最后再合并到主干分支。

然而，在一次特性分支合并到开发分支时，我们遇到了一个棘手的合并冲突。

问题

合并冲突发生在两个分支中对同一文件进行了不同的修改。在我们的案例中，冲突发生在一个 JSON 配置文件中，该文件包含了一组 API 端点的配置数据。

特性分支中，开发人员 A 添加了一个新端点，而开发人员 B 在开发分支中修改了现有端点的配置。当我们尝试合并特性分支时，Git 无法自动解决冲突，并提示我们手动解决。

冲突识别

Git 通过标记冲突行并显示冲突的两侧修改来帮助识别冲突。冲突行通常用 <<<<< 和 >>>>> 分隔，其中 <<<<< 表示冲突前的原有版本，而 >>>>> 表示冲突后的版本。

例如，我们的 JSON 文件中冲突部分如下所示：

{
  "endpoints": [
    {
      "name": "new-endpoint",
<<<<<
      "url": "https://example.com/api/v1/new-endpoint"
>>>>>
      "enabled": false
    },
    {
      "name": "existing-endpoint",
      "url": "https://example.com/api/v1/existing-endpoint",
<<<<<
      "timeout": 1000
>>>>>
      "authentication": "required"
    }
  ]
}

冲突解决

解决冲突的最佳方法是手动合并两侧的修改，创建合并后的新版本。在我们的案例中，我们保留了特性分支中的新端点，并从开发分支中获取了现有端点的配置修改。

解决冲突的步骤如下：

确认冲突行的差异。
决定保留哪一侧的修改，或者合并两侧的修改。
手动编辑文件，移除 <<<<< 和 >>>>> 标记。
保存并提交更改。

在我们的案例中，我们应用了以下修改：

{
  "endpoints": [
    {
      "name": "new-endpoint",
      "url": "https://example.com/api/v1/new-endpoint"
    },
    {
      "name": "existing-endpoint",
      "url": "https://example.com/api/v1/existing-endpoint",
      "timeout": 1000,
      "authentication": "required"
    }
  ]
}