Питання Я зіткнувся з конфліктом злиття. Як я можу перервати злиття?


я використав git pull і виникла конфлікт злиття:

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

Я знаю, що інша версія файлу хороша, і що мій поганий, всі мої зміни слід відмовитися. Як це зробити?


1913
2017-09-19 13:21


походження


Я розумію, що це супер-старе питання, але ви хочете перервати це цілий об'єднайте і залиште гілку, яку ви об'єднали, не занурившись, або просто ігноруйте цей файл як частину більшого злиття, дозволяючи всім іншим файлам об'єднуватися як звичайно? Для мене ваше ім'я означає перше, ваше запитання хоче останнього. Відповіді роблять обидва, не роблячи чітких речей. - rjmunro
Я отримав подібний випадок, коли каже, що автоматичне з'єднання не відбулося; виправити конфлікти, а потім виконати результат: [rejected] gh-pages -> gh-pages (non-fast-forward) - Chetabahana
Гвін, було б корисно вибрати прийняту відповідь тут. Перший голос проголосував трохи менш безпечним, ніж деякі з найсучасніших рішень, тому я думаю, що це допоможе висвітлити інших над нею :) - Amicable


Відповіді:


Оскільки твій pull тоді було невдало HEAD (ні HEAD^) є останньою "дійсною" фіксацією у вашій гілці:

git reset --hard HEAD

Інша частина, яку ви хочете, - це дозволити своїм змінам переоцінити ваші зміни.

Старіші версії git дозволили вам використовувати стратегію об'єднання "їх":

git pull --strategy=theirs remote_branch

Але це з того часу було видалено, як це пояснено в це повідомлення Юніо Хамано (Git maintainer). Як зазначалося в посилання, замість цього ви зробите це:

git fetch origin
git reset --hard origin

1731
2017-09-19 14:33



Замість того, щоб робити жорсткий скидання, ви можете зробити це на більш гранульованому рівні, зробивши: git fetch origin  -> git reset origin (soft reset, your changes are still present)  -> git checkout file_to_use_their_version_of another_file (steamroll your own changes back to match the origin)    Я ніколи більше не використовую гіта. Оскільки в боротьбі між моїм останнім кодом і початком, походження завжди повинно перемагати, я завжди git fetch і git rebase origin. Це фактично робить мої злиття та конфлікти мало і далеко між ними. - Kzqai
Я згоден. Я також спочатку бажаю отримати, а потім вивчити зміни вгорі потоку (git log ..@{upstream} або git diff ..@{upstream}) Після цього, як і ви, я перероблю свою роботу. - Pat Notz
Як зазначено в більш пізньої відповіді, починаючи з версії 1.6.1, можна використовувати "git reset - merge" - Matt Ball
я використав git merge -X theirs remote_branch замість git pull --strategy=theirs remote_branch як theirs виглядає як варіант recursive - mlt
Стратегії немає theirs. - srcspider


Якщо ваша версія Git є> = 1.6.1, ви можете використовувати git reset --merge.

Крім того, як зазначає @ Міхелл Джонсон, якщо ваша версію git є> = 1.7.4, ви також можете використовувати git merge --abort.

Як завжди, переконайтеся, що у вас немає незмінних змін, перш ніж почати злиття.

Від git merge man page

git merge --abort еквівалентно git reset --merge коли MERGE_HEAD присутній.

MERGE_HEAD присутній, коли відбувається злиття.

Також, щодо незмінних змін при запуску злиття:

Якщо у вас є зміни, які ви не хочете робити, перш ніж почати злиття, просто git stash їх перед злиттям і git stash pop після закінчення злиття або переривання його.


1592
2018-03-28 23:16



Цікаво - але керівництво мене налякає. Коли саме це доцільно використовувати? Коли б вам довелося вказати необов'язково <commit>? #GitMoment: -o - conny
Як правило, ви використовуєте це, коли ви хочете повторювати злиття з самого початку. Я ніколи не мав визначати необов'язкове зобов'язання себе, тому за замовчуванням (не обов'язково <commit>) це нормально. - Carl
Я бажаю, щоб у цій відповіді було більше голосів! На цьому етапі, здається, найбільш відповідним рішенням у багатьох випадках. - Jay Taylor
Оскільки git v1.7.4 git merge --abort також працює. - Michael Johnson
Навіть із непоправленими змінами git зміг відновити стан перед злиттям. Приємно! - T3rm1


git merge --abort

Скасуйте поточний процес вирішення конфлікту та спробуйте відновити   попередньо злиття штату.

Якщо в процесі злиття були присутні незмінні зміни, то вони були присутні   почав git merge --abort буде в деяких випадках не в змозі   реконструювати ці зміни. Тому рекомендується завжди   здійснити або призупинити свої зміни, перш ніж запускати гітарне злиття.

git merge --abort еквівалентно git reset --merge коли    MERGE_HEAD присутній.

http://www.git-scm.com/docs/git-merge


378
2017-11-12 21:40



Це було доступно з git v1.7.4. Це псевдонім для перезавантаження git -merge. - Michael Johnson
Не працює з восьминогами конфлікт злиття. - ks1322


У цьому конкретному випадку використання ви дійсно не бажаєте скасувати об'єднання, просто вирішуйте конфлікт певним чином.

Існує не особлива потреба скинути і виконувати злиття з іншою стратегією, або. Конфлікти правильно виділені git, і вимога прийняти сторонні зміни - це лише для цього одного файлу.

Для непогашеного файлу в конфліктному git доступні загальні базові, локальні та віддалені версії файлу в індексі. (Тут їх читають для використання в інструменті 3-way diff за допомогою git mergetool.) Ви можете використовувати git show щоб їх переглянути.

# common base:
git show :1:_widget.html.erb

# 'ours'
git show :2:_widget.html.erb

# 'theirs'
git show :3:_widget.html.erb

Найпростішим способом вирішення конфлікту для використання віддаленої версії verbatim є:

git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb

Або з git> = 1.6.1:

git checkout --theirs _widget.html.erb

73
2017-09-20 10:41



дякую за натяк Хіба це не приємний користувацький інтерфейс git? - Peter
@ Петр: Я не переконаний. Бажаний результат можна досягти за допомогою декількох основних команд з простими варіантами. Які поліпшення ви могли б запропонувати? - CB Bailey
Я думаю, що git 1.6.1 команда робить багато сенсу, і це добре. Це саме те, що я хотів би. Я думаю, що попереднє рішення 1.6.1 неелегантне і вимагає знань про інші частини git, які слід розділити з процесу вирішення об'єднання. Але нова версія чудово! - Peter


Я думаю це git reset тобі потрібно.

Остерігайтеся цього git revert означає щось різне, скажімо, svn revert - в Subversіі повернення буде відкинути ваші (незв'язані) зміни, повертаючи файл до поточної версії з сховища, тоді як git revert "скасовує" фіксацію.

git reset повинен зробити еквівалент svn revert, тобто відкинути ваші небажані зміни.


72
2017-09-19 13:25





Оскільки коментар показує, що git reset --merge є псевдонімом для git merge --abort, варто це помітити git merge --abort лише еквівалентно git reset --mergeвраховуючи те, що a MERGE_HEAD присутній. Це можна прочитати в довіднику git для команди merge.

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

Після невдалої злиття, коли немає MERGE_HEAD, помилка злиття може бути скасована з git reset --merge але не обов'язково з git merge --abort, тому вони є не тільки старим і новим синтаксисом для однієї і тієї ж речі.

Особисто я знаходжу git reset --merge набагато потужніше для сценаріїв, подібних до описаного, і взагалі збігаються.


29
2018-04-02 12:16



що тут означає "невдале об'єднання"? Злиття з конфліктами чи щось інше? Або перефразувати його: коли MERGE_HEAD не присутній? Мій наступний питання полягає в тому, щоб краще зрозуміти використання "git reset --merge". - Ewoks


Оскільки Git 1.6.1.3 git checkout вдалося здійснити перевірку з будь-якої сторони об'єднання:

git checkout --theirs _widget.html.erb

16
2017-07-17 01:29





Альтернативою, яка зберігає стан робочої копії, є:

git stash
git merge --abort
git stash pop

Я взагалі не рекомендую проти цього, тому що це насправді схоже на об'єднання в Subversion, оскільки він відкидає відносини у галузі у наступній фіксації.


14
2017-07-13 18:57



Я знайшов цей підхід корисним, коли я випадково об'єднався з гілкою-svn-гілкою, яка це добре не справляється. Під час роботи з філіями відстеження git-svn краще підібрати сквош або вишні. Насправді моє рішення перетворює злиття в сквош злиття після факту. - Alain O'Dea