好问题！咱们一步步拆解这些Git操作的细节：

默认情况下，git pull是两个操作的组合：git fetch（拉取远程仓库的最新变更）加上git merge（把远程分支的变更合并到本地当前分支）。这种方式会生成一个额外的合并提交，让提交历史出现分叉。

而如果用git pull --rebase，就把合并操作换成了变基（rebase），流程变成这样：

• 第一步还是git fetch，拿到远程的最新提交；
• Git会把你本地当前分支上，所有远程分支没有的提交临时“存”起来；
• 接着把本地分支的指针直接移到远程分支的最新提交上；
• 最后把刚才存起来的本地提交，一个个重新应用到这个最新的基础上。

这么做的好处是能保持提交历史的线性，不会出现多余的合并提交，历史记录看起来更整洁。适合个人开发分支，或者团队提前约定用变基管理历史的场景。

首先要明确：Git Rebase 不是“丢弃”提交，而是改写提交历史。当你执行rebase时，原来的提交会被替换成全新的提交（每个提交的哈希值都会改变），原来的旧提交会变成“悬空提交”——它们不再被任何分支或标签指向，但Git不会立刻删除它们，会默认保留30天，直到Git自动执行垃圾回收（git gc）或者你手动触发清理。

如果你在rebase后用git push --force（更安全的是git push --force-with-lease，能避免不小心覆盖别人刚推送的变更）推送到远程，远程仓库的分支指针会指向新的改写后的提交历史。这时候从远程分支的可见历史来看，原来的旧提交确实“消失”了，但它们其实还在远程仓库的对象数据库里，直到垃圾回收环节才会被清理。

不会。其他开发者的本地仓库已经有那些旧提交的副本了，当他们执行普通的git pull时，Git会检测到本地历史和远程历史不一致（因为远程的历史被改写了），直接报错，不会自动删除他们本地的旧提交。

这时候他们需要手动处理这种冲突场景：

• 推荐用git pull --rebase，把自己本地的提交变基到远程新的历史上，既能对齐远程，又能保留自己的本地提交；
• 如果他们不需要保留自己的本地未推送提交，也可以用git reset --hard origin/<分支名>，强制把本地分支指针对齐到远程，但这个操作会丢失自己的本地提交，一定要谨慎。

不管哪种处理方式，他们本地的旧提交（原来远程的那些）还是会存在，除非他们自己执行git gc清理悬空提交，或者删除相关的引用。

内容的提问来源于stack exchange，提问作者Mandroid