所以，昨天我发布了一个关于一些奇怪冲突的问题，当我试图将上游分支重新定位到我的本地主题分支时。
最后，我使用git rebase --merge upstream并解决了自上次 rebase 以来我没有接触过的文件中的很多冲突。
在这种情况下，我对 rebase 的理解是它将我的提交与该主题分支分离，应用来自上游分支的提交，然后将我的提交（作为补丁）应用到这些之上。因此，它最终成为一个快进操作。我不明白的是......为什么我会与来自上游的提交发生合并冲突。那些也作为补丁应用吗？我认为只是......在来自同一分支的先前提交之上“焊接”一些提交的行为？
我问这个是因为我在我没有接触过的文件中有很多冲突。哦，我每天都用这个上游分支做 rebase。
更新
我刚刚注意到从上游带到我的主题分支的一些提交更改了它们的 SHA-1 id。有谁知道什么可能导致 Git 这样做？会不会是--merge开关？
我的 git 版本是 1.5.6.5
Rebase 重写历史。如果你对已经推送到远程的提交进行 rebase，那么你将进入一个受伤的世界。如果你继续像这样变基，那就更糟了。Rebase有时有它的优势，但它是IMO的专用工具，而不是像合并这样的休闲工具。
然后在这些之上应用（作为补丁）我的提交。
是的，作为新的提交
所以，它最终是一个快进操作
不，快进只是移动该HEAD分支的指针。您正在从远程引入新对象，然后在此之上应用补丁。
如果您的本地和远程最后一次同步在A1，并且说您添加了（本地）A2和A3提交，并且发现远程添加了B1and B2，那么 rebase 将隐藏A2and A3，拉下B1and B2（应该是快进，因为它们共享一个共同的descendant A1），然后将补丁应用于A2和A3 作为新提交（因此是新的 SHA-1）A2'和A3'.
所以现在你的本地历史是：
A1 - B1 - B2 - A2' - A3'
这不是快进。