我听到有人说他们必须在 rebase 期间多次修复完全相同的冲突。这意味着，修复冲突，运行 git rebase --continue，再次遇到相同的冲突，修复它，运行 git rebase --continue 等等。我知道有 git rerere可以记录冲突的解决。
我的问题有点不寻常(但我仍然祈祷它不会被关闭!)。我正在准备一个关于 Git 的研讨会，但我很难想出导致所描述行为的场景。
git rerere文档列出了一个不同的用例，您可以在其中测试 merge ，然后将其重置，但想记住以后真正 merge 的冲突解决方案。这不是我想要的。
我真的在尝试想出上述场景。这是一个神话吗？我想我自己很久以前就观察到了它，但我不是 100% 确定。
有谁知道什么会导致这种行为？
最佳答案
rebase 在分支之上重新应用提交。
从逻辑上讲，如果第一个提交修改了与其应用的提交相同的行，则会产生 merge 冲突。
那么一个场景是:
- 您使用修补程序更新了
master分支 - 当您使用新的实现更改
dev分支中的同一个文件时
当在 master 之上 rebase dev 时，您应该会看到可以记录的 merge 冲突。
在不同的文件上添加第二个修补程序和第二个 rebase :现在应该自动解决第一个 merge 冲突。
I wonder if it's a myth but I had people reporting that they had to apply the exact same conflict resolution for every commit that gets applied during the rebase
如果你在其上 rebase 的分支...已经是force pushed，那么就会发生这种情况。 .
还有(你已经知道了，但我把它包括在其他人那里):
git rerere 在冲突解决方案是跳过正在重新设置基数的特定提交的情况下不会帮助您。
作为mentioned in this thread (以及 yourself in this tweet ):
That is like saying "my hammer is very helpful when I want to hit nails, but sometimes I wish it helped me with screws".
The only thing "
rerere" does is to remember the shape of the conflicted state and desired resolution per file.
It does not tell "rebase" what to do next (you do, via "git add -u" followed by "git rebase --continue").
关于git - 是什么导致了在 rebase 期间必须多次解决完全相同的冲突的情况？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25331916/