git - 如果您处于集中式模型并且从不强制执行， git pull --rebase 是否安全？

Question

关于 rebase 的安全性有很多 git 问题，并且似乎达成共识，只要你记住重写公共(public)历史是粗鲁的，你应该是安全的，即如果没有你没有推送的提交你从中提取的 repo ，你是安全的。

但是有一个答案让我停顿了一下:

https://stackoverflow.com/a/2597107/1339987

Commit to a branch. Push. Merge up to another branch (say you're maintaining two baselines, a patch branch and a new-development branch). Realize other commits have been pushed to the server branch yours is tracking. pull --rebase. Suddenly you've re-made each of the commits against the new hash - and destroyed the merge commit.

我试过玩这个，但无法重现有问题的场景(我可能需要创建一个更复杂的 merge ，但到目前为止还没有这样做)。因此，我要求对这种情况进行解释，并理想地要求一组标准，在这些标准下我可以安全地、相对无意识地依赖 rebase pull 。

Answer 1

上述情况实际上是可能发生的，但后果并不像您可能认为的那么严重。一旦在 git 中提交了某些内容，您至少在 30 天内不会丢失该工作(默认情况下，可通过 git config gc.reflogexpireunreachable 配置)。

如果上述情况发生并且您检测到它，您始终可以恢复到 rebase 之前该分支的前一个提示。您可以通过查看 git reflog 或在 checkout 中指定时间来找到此提示，例如:git checkout 'HEAD@{5 minutes ago}'。

在我使用 git 的这些年里，我从未使用过 git pull --rebase，因为 pull 命令通常在比我想的更高的级别上运行。我更喜欢做同样的事情:

git fetch origin
git rebase -i origin/branch

git rebase 上的显式分支名称和交互选项意味着我始终知道什么正在 rebase 。有时，当我做错事时，我会惊讶地发现我的 rebase 编辑器中有一个巨大的提交列表。

此外，当我处理短期或中期功能时，我几乎总是在本地 rebase ，而不是 merge 上游更改。当我最终将它们推送到中央存储库时，这使我的更改对我来说更加清晰并简化了历史记录。

因此，总而言之，该命令与任何其他 git 命令一样安全，但您需要了解它会做什么以及如何做才能避免出现意外情况。

另请注意:git rebase 有一个选项可以尝试保留 merge 。看起来没有一种简单的方法可以使用 git pull --rebase 来指定它。