git - `git pull --rebase` 什么时候会给我带来麻烦？

Question

我知道当我使用git 时git pull --rebase，git 将重写历史并将我的本地提交移动到我刚刚从中提取的分支中的所有提交之后发生。

我不明白这怎么会是一件坏事。人们谈论陷入麻烦，git pull --rebase因为你最终会得到一个其他人无法拉出的分支。但我不明白这是怎么可能的，因为你所做的只是在你从中拉出的分支上重放你本地的、尚未公开的提交。那么，那里有什么问题呢？

score 27 · Accepted Answer

如果您只发布（推送）了一些提交，这只是一个问题，因为它们将更难合并到已经有这些提交的其他存储库。由于它们的 SHA1 已更改，Git 会尝试在这些存储库上再次重放它们。

如果您还没有（再次推送任何这些提交），那么任何变基都应该是安全的。

所以这里的问题是：你确定你重新定位的所有本地提交实际上仍然是......本地的吗？
你确定' git pull --rebase'之后的那个' git pull --rebase'？

如果您正在处理“私有分支”（您从未推送过的分支，但仅在公共分支上合并或重新设置基础，您将推送的分支），那么您可以随时安全地重新设置该私有分支。

最后，这一切都取决于您选择建立的合并工作流程。

score 5 · Accepted Answer

提交到一个分支。推。合并到另一个分支（假设您要维护两个基线，一个补丁分支和一个新开发分支）。意识到其他提交已被推送到您正在跟踪的服务器分支。拉——变基。突然间，您针对新哈希重新进行了每个提交 - 并破坏了合并提交。

score 4 · Accepted Answer

如果没有人从您那里撤出，并且您没有在其他任何地方推送您的提交（在变基之前），那么理论上您是可以的。但是，Git 旨在很好地处理合并，如果您使用 pull and merge 而不是 pull and rebase，您可能会发现整体工作量会减少。

score 2 · Accepted Answer

请记住，Git 是一个分布式源代码控制系统。人们不必从您推送的中央存储库中提取 - 在某些工作流程中，他们可以直接从您那里提取更改。在这些情况下，重写你的历史肯定会导致你正在谈论的问题

4 回答 4