Конфлікт злиття Git Rebase не може тривати


131

Я намагаюся перезавантажити "dev", щоб наздогнати "master" гілку.

$ git checkout dev 
$ git rebase master 
First, rewinding head to replay your work on top of it...
Applying: Corrected compilation problems that came from conversion from SVN.
Using index info to reconstruct a base tree...
M       src/com/....
<stdin>:125: trailing whitespace.
/**
<stdin>:126: trailing whitespace.
 *
<stdin>:127: trailing whitespace.
 */
<stdin>:128: trailing whitespace.
package com....
<stdin>:129: trailing whitespace.

warning: squelched 117 whitespace errors
warning: 122 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging src/com/....
CONFLICT (content): Merge conflict in src/com/...
Failed to merge in the changes.
Patch failed at 0001 Corrected compilation problems that came from conversion from SVN.

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

$ vi src/com/.....   { fixed the merge issue on one file } 
$ git add -A . 
$ git rebase --continue 
src/com/....: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add
$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue 
Applying: Corrected compilation problems that came from conversion from SVN.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

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

Будь-які ідеї?


Примітка. Є випадки, коли git rebase --skipасистент все ще не працює належним чином. До Git 2.0.2 (липень 2014 р.). Дивіться мою відповідь нижче
VonC

Відповіді:


223

Є кілька ситуацій, коли я бачив, rebaseяк застрягли. Одне полягає в тому, що якщо зміни стають недійсними (комісія має зміни, які вже були внесені раніше в ребазі), в цьому випадку вам, можливо, доведеться використовувати git rebase --skip.

Це досить легко сказати. Якщо ви git statusце зробите, не повинно бути змін. Якщо так, просто пропустіть його. Якщо це не так, будь ласка, опублікуйте його копію, git statusі я можу спробувати допомогти далі.


Ні, це не було, зміни не відбулися. Я пропустив його і порівняв файл, після чого він був таким, яким він мав бути.
awm

Це допомогло мені, коли мій 'git pull --rebase origin master' виявився зациклюватися на циклі між необхідністю вирішити конфлікти та пропустити. Після трохи більше терпіння я виправляюся, ти!
AnneTheAgile

3
статус git повертається: "перезавантаження в процес; в <commitnumber> Ви зараз випускаєте відділення" <ім'я Branch> "на" <номер комісії> ". (всі конфлікти виправлені: запустіть" git rebase --continue ")". git rebase --continue не повертає змін, тоді як git rebase --skip do, але в моєму випадку я отримую цю ситуацію знову і знову. Це правильно чи щось не так?
adi

Дякую. Я хвилювався, що --skipбуде гірше, ніж просто рухатись із змінами, які я вніс.
jchook

У моєму випадку і Intellij Idea GUI, і SourceTree показали, що кожен файл був доданий у фіксацію, тоді як git statusпоказав, що файл був модифікований, але не був доданий у комісію. Виконання add somefile.txtдозволено продовжувати з перезавантаженням.
azizbekian

16

Один з випадків, коли я стикався з цим питанням, - це коли я робив git commitпісля git add. Отже, наступна послідовність призведе до помилки, яку ви згадуєте:

git add <file with conflict>
git commit -m "<some message>"
git rebase --continue

Хоча послідовність нижче працює без будь-яких помилок і продовжує відновлення:
git add <file with conflict>
git rebase --continue

Можливо, що git add -Aз опцією "Усі" створюється подібна ситуація. (Зверніть увагу, я дуже недосвідчений в git, тому ця відповідь може виявитися невірною.) Щоб бути в безпеці, git rebase --skipсхоже, це також добре працює в цій ситуації.


6

Примітка: Git 2.0.2 (липень 2014 р.) Зафіксував один випадок, коли git rebase --skipзастряг і не зможе продовжувати роботу з поточною базою даних.
Див. Комітет 95104c7 від Брайана m. Карлсон ( bk2204)

rebase--merge: виправити --skipз двома конфліктами поспіль

Якщо ви git rebase --mergeзіткнулися з конфліктом, --skipце не спрацювало, якщо б наступний вчинок також суперечив . Файл ніколи не буде оновлюватися з новим номером патча, так що немає патча НЕ буде на самому ділі бути пропущений, що призводить до неминучого петлі.
msgnum

Оновіть значення msgnumфайлу як перше, що відбувається в call_merge.
Це також дозволяє уникнути повідомлення " Already applied" ", коли пропускає комісію.
Немає видимих ​​змін для інших контекстів, у яких викликається call_merge, оскільки значення файлу msgnum залишається незмінним у цих ситуаціях.


3
$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue 

Схоже, ви забули про git addсвої зміни ...


Це було лише "перевірити", ніяких змін не потрібно було вдруге ... git add був прямо над ним.
awm

Правильно, ви використовували, git addа потім продовжували злиття, і він припинився, оскільки інший файл має конфлікти, тому вам потрібно виправити і цей. Я щось тут пропускаю?
Джон Броді

1
Це той самий файл, який звітує, потребує злиття. ОК, просто для вас я зроблю ще один "git add", але це той самий результат.
awm

Дякую! Така моя ситуація: я вирішував конфлікти, але не ставив зміни.
Кирило
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.