如果您处于集中模式并且从未强制推送，那么git pull --rebase是否安全？

Question

4

有很多关于rebase安全性的git问题，似乎有共识认为只要记住重写公共历史是不礼貌的，你就应该是安全的，也就是说，如果你从拉取的仓库中没有推送任何提交，那么你就是安全的。

然而，有一个答案让我感到犹豫：

提交到一个分支。推送。将其合并到另一个分支上（比如你正在维护两个基线，一个是补丁分支，一个是新开发分支）。意识到其他提交已经被推送到了服务器分支，而你的分支正在跟踪这个服务器分支。拉取--rebase。突然间，你重新制作了每个提交的新哈希值，并摧毁了合并提交。

我尝试过这个操作，但无法重现相关场景（也许我需要创建一个更复杂的合并，但迄今为止失败了）。因此，我想请您解释一下这种情况，并在可能的情况下提供一组标准，以便我可以安全地、相对轻松地依赖于rebase拉取。

- djechlin

3个回答

2

如果历史记录是公开的，那么重写历史记录是粗鲁的。如果更改是本地的，则没有人会感到粗鲁。

如果您确实更改了某些内容，并且git pull不仅仅是快进，那么您将得到一个合并操作，从而产生了一段比较混乱的历史记录。如果您的更改尚未完成，我建议使用git pull --rebase，以保持历史记录清洁（并纳入上游更改）。

请注意，任何历史记录的重写都会创建以前不存在的提交，并且从未被阅读/测试过。

- vonbrand

0

这基本上是gerrit的工作原理。只有授权用户才能推送到实际存储库；大多数人只需推送到gerrit审查服务器，然后让gerrit执行合并操作。最终，当您拉取时，您会得到存储库的“集中式”版本，并且相关的repo工具负责始终将您的分支重新基于而不是合并。

在这种模型中，用户始终使用rebase进行拉取。到目前为止，它在Android上运行良好。

- nneonneo

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- djs · Accepted Answer

实际上，所讨论的场景是可能发生的，但其影响并没有你想象中那么严重。一旦在git中提交了某些内容，你至少需要30天（默认情况下，可由git config gc.reflogexpireunreachable进行配置）才能失去这些工作。

如果出现了上述情况，并且你检测到了它，你可以始终恢复到重置之前该分支的上一个提示。你可以通过查看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，而不是合并上游更改。这使得我对自己的更改更加清晰，并在最终将它们推送到中央仓库时简化了历史记录。

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

还要注意：git rebase有一个选项尝试保留合并。似乎没有一种简单的方法来指定使用git pull --rebase。