Git的底墊不會繼續後，刪除/修改衝突

我在我的主人的底墊中的中間階段分支Git的底墊不會繼續後，刪除/修改衝突

git checkout stage 
git rebase master

在一段時間我刪除了兩個文件，然後修改根據這兩個文件到GIT。

warning: too many files, skipping inexact rename detection 
CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree. 
CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation.php left in tree. 
Failed to merge in the changes. 
Patch failed at 0015.

我想說「是混帳，繼續和刪除這些文件」，這樣....

git rm test-recommendation-result.php 
git rm test-recommendation.php 
git rebase --continue

混帳說：

Applying [Bug] Fix test recommender 
No changes - did you forget to use 'git add', Stupid? 

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

我說：「別叫我「愚蠢」，只是做我告訴你要做的事！「

我們現在處於對峙狀態。誰是對的，我如何解決這個問題？

來源

2011-04-01 Clutch

git也稱我太笨 – luckyging3r 2016-11-30 20:36:36

do git add -A其次是git rebase --continue。這應該添加所有更改 - 包括刪除文件，然後繼續。

不保證提交沒有其他文件沒有衝突，應該合併。 git rebase --skip會丟失這些文件。你不想那樣。

希望這會有所幫助。

來源

2011-04-01 17:20:47

總的來說你是對的，但在這種情況下，我們可以推斷沒有其他變化存在。 Git要麼抱怨其他衝突，要麼'rebase --continue'會起作用。 – Cascabel 2011-04-01 19:53:42

這是例外，而不是規則。所有的開發者都應該這樣做，因爲它處理這兩種情況。 – 2011-04-04 18:06:53

你錯過了這一點。這裏的第一步是「檢查git狀態的輸出」。如果它沒有列出任何衝突，也沒有任何分階段發生，那麼跳過是正確的選擇 - 如OP所示，添加/繼續將無所作爲。如果它只列出了所列出的更改，那麼首先沒有衝突，並且可以繼續（問題永遠不會被詢問）。如果存在衝突，問題仍然不會被問到，並且您的回答是危險的 - 您需要在盲目添加所有內容之前解決衝突。 – Cascabel 2011-04-04 18:13:50

當所有其他都失敗時，請閱讀該消息。

此修補程序試圖修改兩個文件，但它們已被刪除;再次刪除它們什麼也沒做。

只需運行git rebase --skip。

來源

2011-04-01 16:53:41

不保證有其他文件被合併正確。跳過跳過會失去這些變化。 – 2011-04-01 17:21:26

哦，我認爲如果其他文件合併正確，rebase就不會抱怨。 – 2011-04-01 17:26:01

問題是它抱怨這兩個文件有衝突。該提交可能不僅僅是那些被更改的2個文件。如果跳過，則跳過這些跳過，而不僅僅是報告衝突的跳過。 – 2011-04-01 17:55:00

當一個提交添加了一個與現有文件衝突的二進制文件時，我點擊了它。

我被它通過：

刪除現有的文件，
使單個字符的變化在不同的文件中評論，
「混帳添加」荷蘭國際集團是無關緊要的變化。

Git很高興再次。 :)

來源

2013-05-30 20:20:07

有沒有一個神奇的命令序列總是運行來解決這種情況。如果有的話，GIT的開發人員只會執行該操作而不會打擾用戶。

請注意，如果您正在櫻桃採摘/移植/反向移動影響重新分解或重命名的文件的更改，也會發生此錯誤。

例如，假設您有支叫support/1.0，看起來像這樣：

 

    com.somewhere.package-a/ 
     MyClass.java 
     MyOtherClass.java

現在，假設1.0版本和1.5之間，這引起了重構。所以現在release/1.5看起來是這樣的：

 

    com.somewhere.package/ 
     a/ 
     MyClass.java 
     ANewClass.java 
     b/ 
     MyOtherClass.java

現在，讓我們說，你從版本1.5，你嘗試備份端口基於斷support/1.0一個特性分支一個特性分支。在該提交中，發佈版本1.5（MyClass.java,ANewClass.java和MyOtherClass.java）中的所有三個文件都發生了變化。

如果您嘗試使用底墊中或純櫻桃挑來幫助背口，一兩件事情可能會發生：

如果文件已經改名爲變化部分被移植，或者在移植的變化的直接父提交中，GIT的內置重命名檢測可能會發現這些文件是具有原始名稱的文件的後代，並且簡單地將更改應用於原始文件。
如果文件已經足夠更名早在版本1.5（後釋放1.0發貨），GIT會告訴你，文件是在release/1.0因爲它沒有知道1.0的哪些文件被刪除的歷史對應於1.5的變化。

ANewClass.java幾乎肯定會引發有關錯誤已被刪除，除非它在的變化是後移植一個補充。

因此，如果您盲目地遵循一組命令來解決這種情況，代碼可能會丟失，這就是爲什麼GIT會提示您手動指導。

來源

2017-04-19 14:19:14 GuyPaddock

Git的底墊不會繼續後，刪除/修改衝突

回答

相關問題