如何改写合并前的Git提交信息且避免解决冲突？

如果你不想在修改历史提交信息时处理大量合并冲突，git replace 是一个非常合适的工具——它可以在不立即重写后续提交的前提下修改目标提交的信息，而且因为我们只修改提交信息（不改动文件内容），后续固化操作也不会产生冲突。

具体步骤： #

1. 定位目标提交
   先找到你要修改的提交的哈希值，用 git log --oneline 查看历史即可，记下目标提交的哈希（比如 abc123）。

2. 基于原提交创建新的提交（仅修改信息）
   切换到目标提交：

   git checkout abc123
   

   然后修改提交信息，注意这里只改信息，不要改动任何文件：

   git commit --amend -m "你的新提交信息"
   

   执行完后，Git会生成一个新的提交哈希（比如 def456），这个新提交的文件内容和原提交完全一致，只有提交信息不同。

3. 用新提交替换原提交
   回到你原来的分支（比如 main）：

   git checkout main
   

   然后用 git replace 把原提交替换成新提交：

   git replace abc123 def456
   

   现在你再用 git log 查看历史，会发现目标提交的信息已经变成新的了！而且这一步完全不会影响后续提交，也不会有冲突。

4. （可选）固化修改（如果需要推送到远程）
   上面的替换只是本地的“虚拟”修改，Git并没有真正重写后续提交的哈希。如果需要把修改推送到远程仓库，就需要固化这个替换，让后续提交都基于新的提交：

   git filter-branch -- --all
   

   这个命令会遍历所有分支和标签，把替换的提交变成真实的提交。因为我们没有修改任何文件内容，所以这个过程不会产生任何合并冲突。

   注意：固化后，后续提交的哈希值会改变，所以推送到远程时需要用 git push --force（如果是共享分支，一定要提前和团队沟通！）

为什么这个方法不会有冲突？ #

原来的 rebase -i 或 rebase -i -p 之所以会触发大量冲突，是因为rebase本质上是将后续提交逐个“重演”到修改后的提交之上——哪怕你只改了提交信息，Git也会重新计算提交的上下文，打破原本的合并关系，进而引发冲突。

而我们用 git replace 的方式，只是修改了提交的元数据（提交信息），完全没有改动提交对应的文件内容（Git中的树对象）。后续提交的内容都是基于原提交的文件内容，而新提交的文件内容和原提交完全一致，所以无论是替换还是固化操作，都不会触发合并冲突。

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