Я столкнулся с конфликтом слияния. Как я могу прервать слияние?

Я понимаю, что это очень старый вопрос, но хотите ли вы прервать слияние весь и оставить ветвь, которую вы сливали, без объединения, или просто игнорируйте этот файл как часть более крупного слияния, позволяя всем другим файлам слиться как нормальный? Для меня ваш заголовок подразумевает первое, а тело вашего вопроса хочет второе. Ответы делают и то, и другое, не проясняя ситуацию.

У меня был аналогичный случай при фиксации, говоря, что автоматическое слияние не удалось; исправить конфликты, а затем зафиксировать результат: [rejected] gh-pages -> gh-pages (non-fast-forward)

Гвин, было бы полезно выбрать здесь принятый ответ. Решение, получившее наибольшее количество голосов, немного менее безопасно, чем некоторые из более современных решений, поэтому я думаю, что это поможет выделить другие :)

Вместо того, чтобы делать полный сброс, вы можете довести его до более детального уровня, выполнив: 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 pull. Поскольку в битве между моим последним кодом и источником всегда должно побеждать происхождение, я всегда использую git fetch и git rebase origin. Это фактически делает мои слияния и конфликты редкими и редкими.

Я согласен. Я также предпочитаю сначала получить, а затем изучить восходящие изменения (git log ..@{upstream} или git diff ..@{upstream}). После этого я, как и вы, перебазирую свою работу.

В дополнение к этому я рекомендую запустить «git clean -f», если у вас еще остались неотслеживаемые файлы, которые вы хотите очистить.

вместо git reset --hard origin у меня работал git branch -r (выберите название ветки), git reset --hard remote/branch.

Как отмечалось в более позднем ответе, начиная с версии 1.6.1 можно использовать 'git reset --merge'

Я использовал git merge -X theirs remote_branch вместо git pull --strategy=theirs remote_branch, так как theirs выглядит как вариант recursive

Стратегии theirs нет.

@mlt, theirs действительно является рекурсивным вариантом, он не существует как собственная стратегия (в текущем git), согласно документации.

git merge --abort намного предпочтительнее.

git fetch origin, а затем git reset --hard origin/master сделали свое дело. Кстати, я использую git версии 2.13.6 (Apple Git-96)

@Kzqai Я использую git pull --rebase после того, как я локально зафиксировал (обычно исправляю, поэтому у меня есть 1 фиксация для каждой функции, по крайней мере, пока я не нажму) свои изменения.

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

спасибо за подсказку. разве это не попахивает плохим пользовательским интерфейсом git?

@ Питер: Я не уверен. Желаемый результат достигается с помощью нескольких основных команд с простыми параметрами. Какие улучшения вы бы посоветовали?

Я думаю, что команда git 1.6.1 имеет большой смысл и хороша. Это именно то, чего я хотел. Я думаю, что решение до 1.6.1 неэлегантно и требует знаний о других частях git, которые следует отделить от процесса разрешения слияния. Но новая версия отличная!

Интересно - но инструкция меня пугает. Когда именно целесообразно использовать? Когда нужно указывать дополнительный <commit>? #GitMoment: -o

Обычно вы используете это, когда хотите повторить слияние с самого начала. Мне никогда не приходилось указывать необязательную фиксацию самостоятельно, поэтому значение по умолчанию (без необязательного <commit>) вполне подойдет.

Я бы хотел, чтобы за этот ответ было больше голосов! На данный момент это кажется наиболее подходящим решением во многих случаях.

Даже с незафиксированными изменениями git смог восстановить состояние до слияния. Отлично!

git merge --abort - это просто синоним git reset --merge? В названии, конечно, больше смысла, но есть ли у него те же функции?

git reset --merge спас мой бекон. Удивительный!

эй @ Карл, не могли бы вы удалить этот ответ? Это сбивает с толку многих, включая меня. git merge --abort - правильный ответ, и он должен быть вверху.

git merge --abort не работает с конфликтом слияния осьминога, работает только git reset --merge.

@Riz: Какие доказательства вы предлагаете в поддержку своего утверждения?

Я нашел этот подход полезным, когда случайно слился с веткой git-svn, которая с этим не справляется. При работе с ветвями отслеживания git-svn лучше использовать сквош-слияния или выбор вишни. Фактически мое решение превращает слияние в слияние в сквош постфактум.

Лучший ответ на вопрос

Чем это будет отличаться от мягкого сброса? Мягкий сброс также сбрасывает репозиторий в исходное состояние, но не затрагивает рабочую копию.

Да, но приходит ли на ум «git reset --soft someref», когда ваша цель - «Как мне прервать слияние?». Как узнать, что использовать для someref? Следовательно, "git merge --abort", который делает правильные вещи и, очевидно, называется освежающим для Git.

Это доступно с git v1.7.4. Это псевдоним для git reset --merge.

что здесь на самом деле подразумевается под «неудачным слиянием»? Слияние с конфликтами или еще что? Или перефразируя это: когда нет MERGE_HEAD? У меня следующий вопрос, чтобы лучше понять использование «git reset --merge».

@Ewoks git stash apply вызвал у меня конфликт слияния, но git merge --abort не помог, а git reset --merge помог.

OP, очевидно, использует командную строку. Ваш пост не имеет ценности.

Я согласен с тем, что очевидно, что OP использует командную строку, но люди, которые не используют командную строку, а исходное дерево и имеют аналогичную проблему, находят этот вопрос вверху в Google (например, я) - поэтому для таких людей этот ответ имеет значение - вот почему Я оставил это здесь :)