当我的一个推送被origin/master恢复时，我最近遇到了一个git问题，但我留在我的分支中继续我的功能，直到它准备好进行最后的推送。当我尝试git pull --rebase时，由于恢复，我的一些本地更改已完全删除。但是，通过pull merge，我能够推送在origin/master上删除的本地文件，因为它触发了冲突。
我试图用本地分支重现这个，但是没有成功。我在分支a上创建了文件develop，将其合并到master，从a合并了已删除的文件master，在{{1}上添加了文件b }}，并尝试将develop合并到master。
此时我希望合并在develop的已删除文件master与开发现有文件a之间产生冲突，但它只是删除了开发文件{{就像我的拉a在我原来的问题中所做的一样。为什么呢？
答案 0 :(得分：3)
这是常见行为，已在the docs中进行了描述。
首先，为什么您的复制不会产生合并冲突？
在合并期间，将更新工作树文件以反映合并的结果。在对共同祖先版本所做的更改中，非重叠版本（即，您更改了文件的某个区域，而另一侧保留了该区域，反之亦然）包含在最终版本中结果逐字逐句。
同一段落中的下一句话描述了为什么在没有origin的情况下将--rebase拉到您的主人身上来创建合并冲突：
当双方对同一区域进行更改时，Git不能随意选择一方而不是另一方，并要求您通过将双方所做的事情留在该区域来解决它。
合并冲突 - 在您的情况下 - 不会创建，因为合并在一起的双方中只有一方影响该文件。如果您在将a合并到该分支之前更改了develop中的文件master，那么就会像pull那样创建合并冲突。在那里，您更改了origin上删除的文件，这会产生合并冲突。