因此，昨天，我在尝试将上游分支重新建立到本地主题分支时，发布了一些奇怪的冲突的question。
最后，我使用了git rebase --merge upstream并解决了自上次重新设置以来从未触及过的文件中的许多冲突。
在这种情况下，我对rebase的理解是，它将我的提交从该主题分支中分离出来，从上游分支中应用提交，然后将我的提交(作为补丁)应用在这些分支之上。因此，它最终是一个快速前进的操作。我不明白的是...为什么我要与那些来自上游的提交 merge 冲突。那些也作为补丁应用吗？我以为只是...在来自同一分支的先前提交之上“焊接”某些提交的行为？
我之所以这样问，是因为我的文件中有很多没有碰到的冲突。哦，我每天都会通过该上游分支机构进行基础调整。
更新
我刚刚注意到，从上游带到主题分支的某些提交的SHA-1 ID已更改。有谁知道可能导致Git这样做的原因吗？可能是--merge开关吗？
我的git版本是1.5.6.5
最佳答案
rebase 重写历史记录。如果您对已经被推送到远程的提交进行重新基准化，那么您将进入一个痛苦的世界。如果您继续像这样 rebase ，那就更糟了。 Rebase有时具有其优势，但是它是IMO的专用工具，而不是像merge这样的临时工具。
是的，作为新提交
不。快速前进只是移动该分支的指针HEAD。您正在从远程引入新对象，然后在其上应用补丁。
如果您的本地和远程最后一次同步于A1，并说您在本地添加了A2和A3提交，并发现远程已添加了B1和B2，则重新设置基础将 stash A2和A3，下 pull B1和B2(应为因为它们共享一个共同的后代(A1)，所以是一个快进)，然后为A2和A3 应用补丁，作为新的提交(因此使用新的SHA-1)A2'和A3'。
因此，您的本地历史记录现在是:A1 - B1 - B2 - A2' - A3'这不是一个快进。