Конфлікт злиття 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.