我经常遇到这样的情况，其中git merge包含很多冲突，可以通过更改一个分支以使其更紧密地匹配来轻松地自动解决。可悲的是，我经常在手动解决了数十个真正需要手动检查的冲突之后才注意到这些模式。中止提交以应用脚本的操作将意味着重做那些操作。
是否有可能从合并返回分支机构，而又不丢弃投入用于手动解决冲突的工作？
如果没有这种可能性，是否有可能在冲突的文件上运行脚本，并随后“自动解决”冲突（两个版本现在都相同）？例如，假设某些文件包含许多形式的冲突
<<<<<<< HEAD
aaaaaaaa \todo{bbbbbbbb} cccccccc
=======
aaaaaaaa \TODO{bbbbbbbb} cccccccc
>>>>>>> other
通过在受影响的文件上运行sed单行代码可以轻松解决这些冲突，但是我不知道一个工具，该工具可以删除`<<<<<< == ===== >>>>>>>“标记。
通常导致此类问题的工作流属于非标准情况，例如：
已收到经过实验修改的快照，作为ZIP文件，后来需要将我的更改合并到存储库中。
相反的情况，即我想将仅作为快照可用的第三方更改合并到我的源中，而没有一个共同的祖先状态被知道：有业余爱好的游戏经验，导致数百行不同只有{sir/madam}成为{reg33?sir:madam}。
通过从程序导出在两个分支上独立创建的文件。除了\todo[inline]和\todoinline之类的细微差异，不同的工作流程导致几乎相同的状态，它们在解决合并冲突时淹没了实际相关的差异。
在合并之前，如果在另一分支上也应用了漂亮打印，则某些文件可能已经漂亮地打印在一个分支上，从而产生了许多冲突，这些冲突将消失。
答案 0 :(得分：2)
是：使用rerere，重新使用重新提供 re 解决方案。
如果您执行git config rerere.enabled true，请打开其〜auto〜模式，在该模式下，合并由于冲突而停止，并在提交结果时再次运行。
即使在您不想提交的情况下，这也很方便，因为您可以到达您正在谈论的地方，已经完成许多解决方案的地方，并且意识到可以避免几乎所有的事情。稍作预处理，然后在中止合并之前手动执行git rerere。
运行rerere时（a）记住新的冲突和新的解决方案，并且（b）将记住的解决方案应用于以前看到的冲突。因此，在您遇到的情况下，启用自动模式（我认为这在记住它的人中几乎是普遍的），它会注意到所有冲突并重新应用您之前显示的所有解决方案，因此当您进入指出您已尽力而为，然后回退并尝试使用手动运行的git rerere预处理数据，它会看到您提出的任何新解决方案，并且会忽略剩余的冲突，因为已经看到了那些以前的东西，对他们来说一无所有。然后中止合并，进行预处理，重新运行合并，自动重命名将解决它可以识别的任何冲突并注意到任何新冲突。
尽管准备好了，但是Git无法识别两个文本不同的块在语义上是相同的，因此，即使您的prettyprinter拆分了行，即使您解决了旧文本中的语义冲突，Git也无法构造类似的文本更改新文本。