是否存在任何常见的git使用错误，或者通常是否有任何原因导致如果这些冲突在之前的rebase中已经解决，那么rebase会重复前一个rebase的冲突？
此外，rebase是否优先考虑如何解决冲突？例如rebase是否希望在代码中常见的git冲突括号中的两个可能的代码片段之间进行严格的选择，或者只是为了删除>>>，<<<之间的所有内容？我很好奇，如果删除两个代码选择来解决冲突会影响rebase正确解决以后冲突的能力。
进一步阐述：
我有一个master分支和一个dev分支。 dev分支我已经在一边工作了一段时间，因此不同提交的数量已经增长了很多，在100年代（我知道......应该dev进入{{1更常见的）。 master分支本身已经有几个较小的特征分支从中切割出来然后合并回来，只是被剪切，重新定位，与dev分支合并，而不是dev分支（我可以记得）。我在1周前将master分支重新定位到dev分支。我已经在master分支上做了一些更改，并希望再次对dev进行更改，以便我可以准备合并。在1周的窗口中，master分支也发生了很小的变化，但代码文件没有重叠。但是，在将master重新定位到dev时，我发现当我尝试当前的rebase时，与我在一周前重新定位时相比，git会引发同一组冲突。
谢谢！
答案 0 :(得分：6)
一般情况下，这是正常的 - 如果你像这样反对而不是合并（例如，master到dev），那么重放相同的补丁可能会产生相同的冲突。
如果这是您工作流程中的常见问题，则可以使用git rerere来记住您的分辨率。