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

Question

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

但我不理解这样做为何会有问题。有人说使用git pull --rebase可能会导致其他人无法从分支上拉取问题，但我不明白为什么会这样，因为你所做的只是在刚拉取的分支上重播尚未公开的本地提交。那么，它存在什么问题呢？

- Gabe Hollombe

Answer 1

只有在您仅发布（推送）了部分提交时才会出现问题，因为它们将更难合并到已经具有这些提交的其他存储库中。由于它们的SHA1已更改，Git将尝试在这些存储库上再次重放它们。

如果您没有（重新推送任何这些提交），任何变基都应该是安全的。

因此，问题在于：您确定所有要变基的本地提交仍然实际上是本地的吗？
并且您确定在'git pull --rebase'之后进行了'git pull --rebase'吗？

如果您正在使用“私有分支”（从未推送过的分支，但仅在公共分支上合并或变基，即将推送的分支），则随时可以安全地变基该私有分支。

最终，所有这些都取决于您选择建立的合并工作流程。

- VonC

---

不一定安全，git pull --rebase 如果失败，实际上可能会丢失它尝试变基的提交。 - ben

@Marius：好问题（对Ben来说是这样，但它已经在这里呆了两个月）。无论Ben在谈论什么失败，仍然有reflog可以获取您刚刚rebase的私有分支的原始提交。 - VonC

我不理解“发布了一些我的提交”是什么意思。这对我来说不清楚，因为我当然已经发布了几百个提交。但是，一旦我正在工作的分支上有任何未完成的更改，git push就会失败，除非我强制执行。这是否意味着如果我们只从集中式存储库拉取，并且永远不进行强制推送，那么它总是安全的？ - djechlin

@djechlin 一个本地仓库可以有多个上游远程仓库；如果在执行 git pull --rebase 命令之前已经将这些提交推送到其他地方，则下一次推送到这些上游仓库时将被强制执行。但即使只有一个上游仓库，也要注意：如果您正在重置的某些提交是您已经推送过的另一个分支的一部分，则会出现问题。您正在使用的分支（和 git pull --rebase）没问题，而其他分支则有问题。 - VonC

@ben，git pull --rebase 只有两种情况会丢失提交记录。

1. 提交记录带来的更改已经在基础代码（你正在 rebase 的历史）中应用过了。
2. 在 rebase 过程中应用提交记录时出现了错误。

- Victor Yarema

Answer 2

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

- John Stoneham

---

但是使用选项“--preserve-merges”来变基不会避免这个问题吗？不幸的是，它似乎无法在配置文件中进行配置。也不确定它是否适用于“git pull --rebase”。 - Marius K

我几分钟前遇到了这种情况...我们该如何避免它？ - gawi

只需查看 git pull --rebase=preserve、git config --global pull.rebase preserve 这些命令的手册（如果需要可以省略关键词 --global）。 - Victor Yarema

Answer 3

如果没有人从您的仓库拉取过代码，并且在rebase之前您也没有将代码推送到其他地方，那么理论上您是安全的。然而，Git旨在处理合并操作，并且如果您执行拉取并合并操作，可能会发现整个工作量更小，比进行拉取和rebase操作更加高效。

- Greg Hewgill

Answer 4

记住，Git是一种分布式源代码控制系统。人们不必从您正在推送到的中央存储库中拉取 - 在某些工作流程中，他们可以直接从您那里拉取其更改。在这些情况下，重写您的历史记录肯定会引起您所说的问题。

- Gareth

---

即使在这种情况下，也可以在接收端进行重建以避免不一致性。 - Victor Yarema