所以，昨天我发布了question关于一些奇怪的冲突，当我试图将上游分支重新绑定到我的本地主题分支时。
最后我使用git rebase --merge upstream并解决了自上一次重组以来我没有触及的文件中的大量冲突。
我在这种情况下对rebase的理解是它将我的提交与该主题分支分离，应用来自上游分支的提交，然后在我的提交之上应用（作为补丁）。因此，它最终成为一个快速前进的操作。我不明白的是......为什么我会与来自上游的提交合并冲突。这些也适用于补丁吗？我认为只是......在同一个分支的前一次提交之上“焊接”一些提交的行为？
我问这个是因为我在未触及的文件中有很多冲突。哦，我每天都会对这个上游分支进行重新定位。
更新
我刚刚注意到从上游到我的主题分支的一些提交已经更改了SHA-1 ID。有谁知道Git会对此做些什么？它可能是--merge开关吗？
我的git版本是1.5.6.5
答案 0 :(得分：3)
Rebase重写历史记录。如果你将已经推送到遥控器的提交重新绑定，那么你正在进入一个受伤的世界。更糟糕的是，如果你继续像这样下降。 Rebase有时会优先使用它，但它是一个专业工具IMO，而不是休闲工具，比如合并。
然后在我的提交之上应用（作为补丁）。
是，作为新提交
因此，它最终成为一个快进的操作
没有。快进只是移动该分支的指针HEAD。您将从远程引入新对象，然后在其上应用修补程序。
如果您的本地和远程用户在A1处最后同步，并说您添加了（本地）A2和A3次提交，并且发现该远程已添加{{1} }和B1，重新定位将隐藏B2和A2，下拉A3和B1（应该是快进因为他们有共同的后代{ {1}}），然后将B2和A1 的修补程序应用为新提交（因此新的SHA-1）A2和A3 。
所以现在你的当地历史是：
A2'
这不是一个快进的人。