如何通过编程方式解决Git变基时的合并冲突？

我有一个包含各类变更的分支mybranch，需要将其变基到master分支上。mybranch当前基准与目标基准的差异仅为一个名为replace的提交，该提交将大部分（非全部）foo替换为bar，此操作可在任意版本重复执行。

提交历史如下：

* 46de000 (mybranch) my latest change
* ...
* 452e6f5 my second change
* 452e6f4 my first change
| * dc5024d (origin/master, master, tag: replace) replace /foo/bar/
|/  
* 5fab176 common base
* 7bbe99e initial commit

mybranch中的提交并未修改foo本身，但修改了多个包含foo的行。因此将mybranch变基到replace时会产生大量手动难以处理的合并冲突，这些冲突无法自动解决，因为replace与mybranch的提交对同一行做了不同修改。

由于bar仅在replace中引入，其他提交均未包含该词，因此可制定如下冲突解决规则：

if base.contains('foo') and local.contains('bar'):
   return remote.replace('foo', 'bar')
else:
   exit('unexpected conflict: $remote $local $base')

请问是否存在可传入此类规则的工具？

编程化方式 #

• git-filter-repo批量重写历史：认为无法通过修改mybranch来避免合并冲突。
• gitPython：工具看似可行，但合并冲突解决功能尚未实现，且项目处于维护模式。

手动方式 #

更倾向于编程化解决方案，但此处也整理了一些手动方案：

• 在mybranch上应用替换操作：若我是仓库所有者此方法可行，但实际并非如此，replace已在origin/master上，无法移除。
• 在mybranch上应用替换操作并合并，再变基到master：在mybranch上添加一个执行替换操作的新提交replace_on_top，将所有提交合并为一个后，可通过git rebase -Xtheirs master变基到master。缺点是会丢失mybranch原有的提交拆分结构，或许可将replace_on_top自动分发到mybranch中首次修改对应文件的提交，以保留原有提交结构。
• 使用GUI或IDE工具：冲突数量过多，即使借助IDE也难以手动处理。
• 将mybranch合并到master：此方法比重变基简单，冲突一次性出现，但我更希望采用变基方式。

1. Git 自定义合并驱动（推荐） #

Git允许通过自定义合并驱动实现你制定的冲突解决规则，步骤如下：

1. 编写冲突解决脚本：创建resolve-foo-bar-conflict.py脚本，实现规则逻辑：

   import sys
   
   def resolve_conflict(base_path, local_path, remote_path):
       with open(base_path, 'r') as f:
           base = f.read()
       with open(local_path, 'r') as f:
           local = f.read()
       with open(remote_path, 'r') as f:
           remote = f.read()
   
       if 'foo' in base and 'bar' in local:
           return remote.replace('foo', 'bar')
       else:
           print(f"unexpected conflict: {remote_path} {local_path} {base_path}", file=sys.stderr)
           sys.exit(1)
   
   if __name__ == "__main__":
       if len(sys.argv) != 4:
           print("Usage: resolve-foo-bar-conflict.py <base> <local> <remote>", file=sys.stderr)
           sys.exit(1)
       result = resolve_conflict(sys.argv[1], sys.argv[2], sys.argv[3])
       print(result)
   

2. 配置Git使用该驱动：
   • 在仓库根目录的.git/config中添加：

     [merge "foo-bar-resolver"]
         name = Custom resolver for foo/bar conflicts
         driver = python3 path/to/resolve-foo-bar-conflict.py %O %A %B
     

   • 在.gitattributes文件中指定应用该驱动的文件（可指定所有文件或特定后缀）：

     * merge=foo-bar-resolver
     

3. 执行变基：运行git rebase master，Git会自动调用脚本处理符合规则的冲突。

2. 结合git rebase --exec与冲突处理脚本 #

如果不想全局配置合并驱动，可在变基过程中自动调用脚本解决冲突：

1. 编写auto-resolve-conflicts.sh脚本：

   #!/bin/bash
   for file in $(git diff --name-only --diff-filter=U); do
       # 获取冲突文件的三个版本
       git show :1:"$file" > /tmp/base.tmp
       git show :2:"$file" > /tmp/local.tmp
       git show :3:"$file" > /tmp/remote.tmp
   
       # 调用处理脚本并写入结果
       python3 path/to/resolve-foo-bar-conflict.py /tmp/base.tmp /tmp/local.tmp /tmp/remote.tmp > "$file"
   
       # 标记文件为已解决
       git add "$file"
   done
   

2. 执行变基：

   git rebase master --exec "bash path/to/auto-resolve-conflicts.sh"
   

   若遇到不符合规则的冲突，脚本会退出，需手动处理后执行git rebase --continue。

3. git rerere 重用冲突解决方案 #

如果冲突模式固定，可使用git rerere自动复用已记录的解决方案：

1. 启用功能：

   git config --global rerere.enabled true
   

2. 手动解决一个典型冲突并提交，rerere会记录该冲突模式。后续遇到相同模式的冲突时，Git会自动应用之前的解决方案。此方式适合冲突模式高度一致的场景，灵活性略逊于自定义脚本。

内容的提问来源于stack exchange，提问作者peer