假设以下git历史记录
M (master) <- merge that required resolving a conflict, e.g. coming from F and G
| \
| |
F G
| |
C D <- commit to edit (D), unrelated to the merge conflict (e.g. adding a new file)
| |
| /
B
|
A <- initial commit
我想要实现的是编辑提交D（重写历史记录）。我使用命令git rebase --interactive --preserve-merges A master，标记要编辑的提交D，在重新定位停止时编辑它，修改提交和git rebase --continue。
我在M提交之前收到的是解决冲突的请求。将分支合并到M时，已经解决了相同的冲突，因此我预计rebase将顺利进行。
$ git rebase --continue
Auto-merging yet-another-test.txt
CONFLICT (content): Merge conflict in yet-another-test.txt
Automatic merge failed; fix conflicts and then commit the result.
Error redoing merge d01ffb203aae9ef450ae7a863de5fce2ed5184bb
您可以找到示例here，例如，您可以尝试git rebase -i -p 8b58 master和edit 30c7提交
我问的原因是因为我的真实仓库的git历史很复杂，一路上有很多合并（总共大约300次提交），我需要编辑的提交接近最初提交，所以我想保留历史记录（避免挤压），但我宁愿不再解决所有冲突。
有更好的方法吗？
尝试使用git for windows 2.17.1（最近）。
答案 0 :(得分：2)
默认情况下，Git不记录以前的合并解决方案，这就是当rebase必须重新创建合并提交时，您会遇到完全相同的冲突的原因：
Error redoing merge d01ffb203aae9ef450ae7a863de5fce2ed5184bb
这是git-rerere（重复记录的分辨率）的来源：
此命令通过在初始手动合并中记录冲突的自动注射结果和相应的手部分辨率结果，并将先前记录的手部分辨率应用于相应的自动注射结果，帮助开发人员完成此过程。
要让Git开始记录合并解决方案，首先需要在存储库（或全局）中启用rerere，然后说：
git config rerere.enabled true
或
git config --global rerere.enabled true
不幸的是，它不会帮助您节省这个特定实例的时间 - 因为您已经已经解决了各种合并提交中的冲突，但是它会有所不同前进。
编辑：实际上，似乎有办法通过运行名为rerere-train的shell脚本来记录现有合并提交中的以前的分辨率。我自己也没试过，所以YMMV。