应用git patch时出现冲突是否正常？冲突原因及高效解决方法咨询

1. 应用git patch过程中出现冲突是否属于正常现象？ #

属于正常现象。git补丁的自动应用逻辑要求补丁修改的代码段，在目标仓库中的上下文和生成补丁时源仓库对应代码段的内容完全一致，只要目标仓库对应位置的代码发生了和补丁内容不一致的改动，就会触发冲突。之前操作未遇到仅说明之前目标仓库的代码和补丁生成的基准完全匹配，不代表冲突是异常问题。

2. 多commit补丁批量冲突的高效处理方案 #

可以根据你的需求选择以下方案：

• 如果不需要保留dev分支的所有提交记录，直接一次性合并全量改动：
  可以在copy repo中将main repo添加为临时远程源，直接合并dev分支，仅需要处理一次最终冲突，不需要逐个处理50个commit的冲突，操作命令如下：

  # 在copy repo中执行
  git remote add temp_main <main repo的本地路径/远程地址>
  git fetch temp_main
  git merge temp_main/develop
  

  不想添加临时远程源也可以在main repo生成全量diff补丁：

  # 在main repo的dev分支执行
  git diff origin/master origin/develop > ../full_dev.patch
  

  然后在copy repo应用全量补丁，冲突也会一次性暴露：

  git apply full_dev.patch
  

• 如果必须保留所有提交记录，可以先在main repo中将dev分支rebase到最新master分支，在源仓库先解决完所有rebase冲突后再重新生成补丁，新补丁在copy repo应用时冲突概率会大幅降低。
• 也可以给git am添加--reject参数，应用补丁时不会中途停止，应用失败的改动会生成.rej后缀的文件，全部补丁处理完成后统一处理所有.rej文件的冲突即可。

3. 冲突的常见产生原因 #

你提到的合并提交是高频原因之一，其他常见原因如下：

• 合并提交问题：git format-patch默认不会导出合并提交的内容，仅会导出合并分支上的线性提交，这些提交的代码上下文是基于合并前的旧代码，并非基于master分支，应用到copy repo的master分支时就会出现大量上下文不匹配的冲突。
• 目标仓库存在未同步改动：copy repo的master分支在上次同步后有未同步到main repo的改动，哪怕是换行符、注释的改动，都会导致补丁应用失败。
• 基准commit不匹配：两个仓库的master分支虽然内容同步，但如果有过rebase、reset等修改提交历史的操作，两者master分支的最新commit哈希不一致，也会导致补丁的基准校验失败触发冲突。
• 源分支提交历史被修改：main repo的dev分支有过rebase、amend等修改提交历史的操作，生成补丁对应的提交上下文和master分支的内容不匹配。

内容的提问来源于stack exchange，提问作者Fatemeh.M