关于 rebase 的安全性有很多 git 问题，并且似乎达成共识，只要你记得重写公共历史是粗鲁的，你应该是安全的，即如果没有任何提交你没有推送到 repo你正在拉，你是安全的。
但是，有一个答案让我停下来：
https://stackoverflow.com/a/2597107/1339987
提交到一个分支。推。合并到另一个分支（假设您要维护两个基线，一个补丁分支和一个新开发分支）。意识到其他提交已被推送到您正在跟踪的服务器分支。拉——变基。突然间，您针对新哈希重新进行了每个提交 - 并破坏了合并提交。
我试着玩这个，但无法重现有问题的场景（我可能需要创建一个更复杂的合并，但到目前为止还没有这样做）。所以我要求对这种情况进行解释，最好是一组标准，在这些标准下，我可以安全且相对盲目地依赖 rebase pulls。
有问题的情况实际上是可能的，但后果并不像你想象的那么严重。git config gc.reflogexpireunreachable一旦在 git 中提交了某些内容，您至少不能在 30 天内丢失该工作（默认情况下，由 配置）。
如果发生上述情况并且您检测到它，您始终可以在变基之前恢复到该分支的上一个提示。您可以通过查看git reflog或指定结帐时间来找到此提示，例如：git checkout 'HEAD@{5 minutes ago}'。
在我使用 git 的这些年里，我从来没有使用过，git pull --rebase因为 pull 命令的运行水平通常比我想的要高。我更喜欢做同样的事情：
git fetch origin
git rebase -i origin/branch
明确的分支名称和交互选项 ongit rebase意味着我始终知道正在重新设置的内容。有时，当我做错事时，我会惊讶地发现我的变基编辑器中有一个巨大的提交列表。
此外，当我在开发一个短期或中期功能时，我几乎总是在本地进行 rebase，而不是合并上游更改。当我最终将它们推送到中央存储库时，这使我的更改对我来说更加清晰并简化了历史记录。
因此，总而言之，该命令与任何其他 git 命令一样安全，但您需要了解它会做什么以及如何做到这一点，以免出现意外情况。
另请注意：git rebase可以选择尝试保留合并。看起来没有一种简单的方法可以用git pull --rebase.
如果历史已经公开，重写历史是不礼貌的。如果更改是本地的，那么没有人可以粗鲁。
如果你确实改变了一些东西，并且 agit pull不仅仅是快进，你会得到一个合并，因此历史会有点混乱。如果您的更改尚未完成，我更愿意使用它git pull --rebase来保持历史整洁（并合并上游更改）。
小心，任何历史重写都会创建以前从未存在过的提交，因此没有被读取/测试。
这基本上就是gerrit 的功能。只有授权用户推送到实际的仓库；大多数只是推送到 gerrit 审查服务器，让 gerrit 进行合并。最终，当您拉取时，您将获得存储库的“集中式”版本，并且相关repo工具负责始终重新定位您的分支而不是合并。
在这个模型中，用户总是使用 rebase 拉取。到目前为止，它在 Android 上运行良好。