git pull合並完全合並分支的沖突

Question

這不是一個重復的git pull從干凈的目錄有合並沖突 - 在那個問題中，用戶試圖從一個提交不同於本地分支的遠程提取。 在我的情況下，遙控器上沒有提交，也不在我的本地分支中。

首先，這是我的git狀態：

asj@asj] git fetch
asj@asj] git status
# On branch project
# Your branch is ahead of 'origin/project' by 17 commits.
#   (use "git push" to publish your local commits)
#
nothing to commit, working directory clean

正如你所看到的那樣，我在我自己的項目分支上，在原點/項目之前提交了17個提交。 當我運行git log作為差異時，它列出了項目中17個不在源/項目中的提交：

asj@asj] git log project ^origin/project
<shows all 17 commits>

到目前為止一切順利，現在我檢查源項目/項目中尚未進入項目的提交：

asj@asj] git log origin/project ^project
<shows nothing>

正如預期的那樣，我的本地項目分支中沒有任何東西丟失。 本地分支完全合並。 現在我在推送我的17次提交之前運行git pull作為最佳實踐。 我希望這告訴我，我已經是最新的：

asj@asj] git pull
First, rewinding head to replay your work on top of it...
Applying: SomeEarlierChange
Using index info to reconstruct a base tree...
M       SomeFile
Falling back to patching base and 3-way merge...
Auto-merging SomeFile
CONFLICT (content): Merge conflict in SomeFile
Failed to merge in the changes.
Patch failed at 0001 SomeEarlierChange
The copy of the patch that failed is found in:
   SomeDirectory/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

這不是我的預期。 當我一起玩並解決SomeFile中的沖突然后git rebase - 繼續它會在更多文件中出現更多沖突。 我經歷了幾次迭代，繼續沿着這個兔子洞走下去，但我不認識到我看到的任何變化或它們可能來自哪里。 我已經完成了整個過程幾次，並且總是最終運行git rebase --abort並返回到本文開頭所描述的情況。

我想簡單地將這17個新提交的更改推送到遠程，因為項目迫切需要它們。 但是，我擔心這會導致更多神秘的沖突，而且我最終會花一整天時間修復遠程分支而不是本地分支。 在推動之前，我想解決一下我遇到的困難。

我能想到的唯一相關的事情是本地分支上的一些提交是從第三個分支合並而來的。 這些提交可能與項目和原產地/項目之間的歷史相沖突嗎？ 我擔心git現在認為origin / project的歷史是新的和不同的，需要在拉動時合並到項目中（即使它不包含新的提交）。 這可能是這種情況嗎？ 我該如何解決這個問題？

關於這里可能會發生什么的任何其他想法？

Answer 1

你有git pull set來做一個自動rebase （而不是自動合並），所以這是粗略的git fetch; git rebase project origin/project git fetch; git rebase project origin/project 。

如果所有提交都是線性的，那么在git fetch沒有Current branch project is up to date.任何新提交之后，rebase將是一個no-op，並且你會得到Current branch project is up to date. 信息。 但是，正如您所說，您的提交包括另一個分支的合並提交。 這是事情出錯的地方，因為rebase試圖平息合並。 （如果你使用--preserve-merges進行rebase，它可能會沒問題。）

這里要認識到的主要事情是沒有必要在這里運行git pull 。 Pull只是fetch-then-merge（如果配置為rebase，則為fetch-then-rebase，就像你的那樣）。 這里的想法是確保你擁有來自遙控器的所有提交。 一旦你這樣做，你就可以git push它們git push回到遙控器，結果將是遙控器的快進操作。

它不是快進的唯一一次是當別人偷偷進入你可以git push並將他們的提交添加到遠程存儲庫之前。 ¹在這種情況下，你必須git fetch它們的提交，然后以某種方式將它們與你的提交組合在一起（通常是一個rebase或一個合並 - 即git pull做什么！），然后重試你的推送。 如果這種情況發生在十秒內，而第三組在9秒或更短的時間內推送新的提交，則會再次出現“非快進”錯誤，並且必須重復此過程（如果你的速度較慢，可能會永遠重復比其他人都多，但實際上這很快收斂了）。

使用git pull並不能保證你是最快的並且“贏得”“推動競賽”，這只是在觀察錯誤后進行“獲取，然后合並或重組”步驟的便捷方式。 你可以簡單地嘗試推送，看看你是否得到錯誤...如果是這樣，使用git fetch而不是git pull ，然后自己決定如何處理“失去”“推擠競賽”。

---

¹好吧，有一兩個其他情況，當有人強行推送“倒帶”或“重置”分支名稱，或刪除並重新創建分支，或重命名它，或者通常導致整個分支名稱-to-commit-ID映射以某種不尋常/意外的方式進行更改。 但這些都不是正常情況，除非提前談判（有些項目有特定的“可重置”分支，你不應該依賴於“正確”行為，用git術語）。

Answer 2

您是否嘗試過創建新的跟蹤分支並合並您的提交？

基本上我的建議是：

git checkout -b project_1 origin/project
git merge project

您可以在合並時使用--squash選項同時支持所有17次提交。