背景&问题

我有一个master分支，然后基于此创建了一个a分支，又基于a创建了一个b分支。后续a进行了迭代，最后合入master，并且进行了发版。然后我在b分支merge master时发现有很多之前历史已经解决过的冲突，如何有效解决？

方案

在该情景中，历史冲突重复出现的原因是由于 b 分支的基线和最新的 master 分支之间的差异。具体来说：

1. b 分支创建时的基线是旧的 a 分支的状态：

   • 当 a 分支完成后合并到 master 并进一步迭代时，这些修改对于 b 分支来说是新的内容。
   • 但是在 b 分支中可能已经有部分与 a 或 master 的变更重叠或冲突。

2. Git 的合并算法会尝试重新解决冲突：

   • 如果 b 分支中的某些代码在之前的合并（a -> master）中已经被修改过，Git 无法自动确定应该选择哪些变更，从而导致重复冲突。

解决方式

为了避免这种情况，以下是处理这种历史冲突的方法：

1. 直接将 master 合并到 b 分支

• 首先将 master 的最新代码同步到 b 分支：

  git checkout b
  git merge master
  

• 解决冲突时，尽量选择与 master 保持一致，尤其是对于已经在 master 中解决过的冲突。

2. 重建 b 分支（如果冲突过多，建议此方式）

如果 b 分支的代码与 master 的变更过于复杂，可以考虑以下步骤：

• 基于最新的 master 创建一个新分支：

  git checkout master
  git pull
  git checkout -b b_new
  

• 将 b 的变更引入 b_new：

  git cherry-pick <b 分支的 commit ID>
  

  或者直接使用 git rebase：

  git checkout b
  git rebase master
  

• 通过这种方式，可以减少不必要的冲突并保持历史清晰。

3. 使用 Git 的“ours”或“theirs”策略解决冲突

在某些特定情况下，如果你非常确定 master 的变更应该覆盖 b 的变更，可以使用 git merge 的 --strategy-option 参数：

git merge -s ours master

或者：

git merge -s theirs master

注意：这种方法会强制选择一个分支的变更，可能会丢失部分改动。

总结

如果发现历史冲突反复出现，推荐使用 rebase 或 重新创建分支 的方式来简化冲突处理流程。未来开发时，尽量确保分支基线尽早与 master 同步，以减少后续合并的复杂性。