Git Rebase重复发生来自上次Rebase的冲突

Question

是否存在任何常见的git使用错误或者一般情况下有任何原因，为什么如果这些冲突已在之前的rebase中全部解决，为什么rebase会重复来自之前rebase的冲突？
此外，rebase是否有优先于冲突解决的方式？例如rebase是否希望在代码中通常的git冲突方括号内的两个可能的代码片段之间进行严格的选择，或者仅仅是为了取消>>>,<<<之间的所有内容？我很好奇，如果删除两个代码选项来解决冲突将影响rebase的正确解决后续冲突的能力。

进一步细化： 我有一个master分支和一个dev分支。 dev分支我一直在一边工作一段时间，所以不同提交的数量已经增长得相当大，在100年代（我知道......应该dev到更多的master）。 dev分支本身已经有几个较小的特征分支从它切下，然后合并回来，只有被切割，重新设计，与dev分支合并，从未master分支（我记得）。我在1周前将dev分行重新分配到master分行。我已经在dev分支上做了一些更改，并且希望再次兑换master，以便我可以准备合并。在该1周的窗口中，master分支也发生了非常小的变化，但代码文件不重叠。然而，当将dev重新编号为master时，我发现当我尝试使用当前的重新分档时，与我在一周前重新启动时相比，git引发了相同的一组冲突。

谢谢！

Answer 1

一般来说，这是正常的 - 如果你像这样重新绑定而不是合并（例如master到dev），那么重放相同的补丁可能会产生相同的冲突。

如果这是您工作流程中的常见问题，则可以使用git rerere来记住您的解决方案。