什么時候`git pull --rebase`讓我陷入困境？

Question

據我所知，當我使用git pull --rebase ，git將重新編寫歷史記錄，並在我剛剛提取的分支中的所有提交之后移動我的本地提交。

我不明白的是這將是一件多么糟糕的事情。 人們談論用git pull --rebase來解決問題，你最終會得到一個其他人無法接受的分支。 但是我不明白這是怎么回事，因為你所做的就是在你所從的分支上重播你當地的，尚未公開的提交。 那么，那里的問題是什么？

Answer 1

如果您只發布（推送）了一些提交，那么這只是一個問題，因為它們將更難合並到已經提交過的其他repos。 由於他們的SHA1已經改變，Git的會再次嘗試重播他們的回購協議。

如果你還沒有（再次推送任何提交），任何rebase應該是安全的。

所以這里的問題是：你確定你所做的所有本地提交實際上仍然是......本地的嗎？
在' git pull --rebase '之后你確定' git pull --rebase '嗎？

如果您正在處理一個“私人分支”（一個您從未推動過的分支，但只在公共分支上合並或變基，您將推送的分支），那么您可以隨時根據需要重新定義該私有分支。

最后，這一切都取決於您選擇建立 的合並工作流程 。

Answer 2

致力於分支機構。 推。 合並到另一個分支（假設您正在維護兩個基線，一個補丁分支和一個新開發分支）。 實現其他提交已被推送到您正在跟蹤的服務器分支。 拉 - 基地。 突然你已經針對新哈希重新提交了每個提交 - 並破壞了合並提交。

Answer 3

如果沒有人從你那里撤走，你還沒有在其他任何地方推動你的提交（在rebase之前），那么理論上你沒問題。 但是，Git旨在很好地處理合並，如果你使用pull和merge而不是pull和rebase，你可能會發現總體上工作量較少。

Answer 4

請記住，Git是一個分布式源代碼控制系統。 人們不必從您正在推動的中央存儲庫中提取 - 在某些工作流程中，他們可以直接從您那里獲取更改。 在這些情況下，重寫您的歷史肯定會導致您正在談論的問題