我 git 變基了嗎？

Question

我回到了幾周前（假期前）我正在處理的一些代碼。 我根據合並請求中留下的一些評論進行了更改。

我去推送我的更改，但出現錯誤：

 ! [rejected]        my_branch -> my_branch (non-fast-forward)
error: failed to push some refs to '<remote>:my_repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

我認為這是我在 rebase 后嘗試推送時收到的消息（需要強制推送）； 但是，我不記得變基（我可能有，只是不記得了）。

當我真的不知道我在推動什么時，我會猶豫是否強制推動。

所以我的問題是：有沒有辦法檢查我的分支機構（特別是我的本地分支機構）是否已重新定位？ 除了 rebase 之外，是否還有其他可能導致此錯誤的原因（如果沒有，那么我可能會假設我幾周前剛剛做了 rebase，並且強制推送可能是安全的）？ 關於如何安全處理這種情況的任何其他建議？

Answer 1

非快進錯誤可能是由於您在另一個貢獻者剛剛推送不同的新提交時嘗試推送新提交。 檢查它的方法是git fetch ， git diff origin/my_branch和git log origin/my_branch..my_branch 。 補救的方法是git pull --rebase origin my_branch或者

git fetch origin
git rebase origin/my_branch my_branch
git push origin my_branch

Answer 2

您通常收到的消息¹表示您的分支機構與遠程分支機構存在分歧。 最常見的情況是：

1. 在之前推送你的分支之后，你通過將你的分支變基到它的較新版本來集成來自遠程基礎分支的最新更改，可能是origin/main 。
2. 在之前推送你的分支之后，你交互式地重新設置了你自己的分支或修改了你的提示提交。
3. 其他人將提交推送到您的分支。

了解它是什么很重要，因為您應該對#1 和#2 采取的操作是強制推送，而您應該對#3 采取的操作是拉取（通過合並或變基），或將您的分支變基到遠程版本 - 有關解決場景 #3 的詳細信息，請參閱phd 的答案。

無論哪種情況，您都絕對不想弄錯，因為：

• 如果您處於場景 #1 或 #2 中，使用合並進行拉取將帶回您的舊提交。 （如果您不注意，這很糟糕。）
• 在場景 #1 中變基到遠程將重寫來自共享分支的所有新提交。 （如果你不注意，這真的很糟糕。）
• 場景 #3 中的強制推送會吹走其他人的提交。 （如果你沒有注意到，這從糟糕到非常糟糕，這取決於那個人有多好。）

所以把它做好很重要。 根據你的第一句話：

我回到了幾周前（假期前）我正在處理的一些代碼。 我根據合並請求中留下的一些評論進行了更改。

我認為可以安全地假設兩件事：

0. 你用的是GitLab。（我只知道這個是因為你說的是MR而不是PR，這當然是無關緊要的。。。）
1. 您根據建議對代碼進行了一些更改。 如果你修改了你的提示提交，這會導致場景#2。 如果您創建了一個包含更改的新提交，那么 3 種情況中的任何一種都是可能的（如果您在#1 或#2 周前沒有推送）和/或有人向您的分支添加了新提交。

現在讓我們看看發生了什么：

這種情況經常發生在我身上。 我切換到我希望工作的個人分支之一，我輸入git status ，看到我的分支已經從遠程分支，例如它告訴我我提前 300 次提交，落后 2 次。 在這種情況下，我知道我重新定位了，但我可能仍然會看：

git log @{u} -n3 # show me the top 3 commits of my remote branch
git log @ -n3 # show me the top 3 commits of my local branch

我希望看到相同的 2 個提交具有相同的作者（我）和作者日期，但具有不同的提交 ID。 第三次提交在我的本地分支上應該是更新的，這意味着我只是重新定位到基礎分支的更新版本。 （場景#1）

請注意，如果我的分歧數是 2 和 2，並且第 3 次提交是相同的 ID，那么這意味着我可能沒有在目標上變基，而是進行了交互式變基或修改（場景 #2），這使得查看變得容易差異：

git diff @{u} @

總的來說，我傾向於總是使用git push --force-with-lease ，所以在看到我可以推送之后我很有信心。 如果--force-with-lease仍然失敗，我只需git fetch ，然后git status ，並重復上述步驟以查看我遺漏了什么。

如果在比較日志時你看到其他人在遠程分支上的提交，那么你知道其他人推送了一個提交，你需要將它帶到你的分支中，這樣你就不會把它吹走。 如果您處於場景 #1 和/或 #2，以及場景 #3，這意味着有人將提交推送到您的舊版本分支，那么您可能需要使用rebase --onto選項上。

---

¹獲取此消息的另一種可能方法是，如果您沒有分歧，而是僅在遠程分支后面。 在這種情況下，雖然您沒有任何新的提交要推送，但您可以簡單地執行git merge或git pull或git reset --hard @{u} ，甚至git rebase @{u}所有這些都會有同樣的效果。