Невозможно завершить оформление заказа, так как у вас есть не объединенные файлы

Обновлено: 02.07.2024

Системы контроля версий предназначены для управления вкладами между несколькими распределенными авторами (обычно разработчиками). Иногда несколько разработчиков могут пытаться редактировать один и тот же контент. Если разработчик А попытается отредактировать код, который редактирует разработчик Б, может возникнуть конфликт. Для предотвращения возникновения конфликтов разработчики будут работать в отдельных изолированных ветках. Основная задача команды git merge – объединить отдельные ветки и разрешить любые конфликтующие изменения.

Понимание конфликтов слияния

Слияние и конфликты — обычная часть работы с Git. Конфликты в других инструментах контроля версий, таких как SVN, могут быть дорогостоящими и трудоемкими. Git упрощает слияние. В большинстве случаев Git найдет способ автоматически интегрировать новые изменения.

Конфликты обычно возникают, когда два человека изменили одни и те же строки в файле или если один разработчик удалил файл, пока другой разработчик его модифицировал. В этих случаях Git не может автоматически определить, что правильно. Конфликты затрагивают только разработчика, проводящего слияние, остальная часть команды не знает о конфликте. Git пометит файл как конфликтующий и остановит процесс слияния. В этом случае ответственность за разрешение конфликта лежит на разработчиках.

Типы конфликтов слияния

Слияние может войти в конфликтное состояние в двух разных точках. При запуске и во время процесса слияния. Ниже обсуждается, как действовать в каждом из этих конфликтных сценариев.

Git не может начать слияние

Слияние не запустится, если Git обнаружит изменения либо в рабочем каталоге, либо в промежуточной области текущего проекта. Git не может начать слияние, потому что эти ожидающие изменения могут быть перезаписаны коммитами, которые объединяются. Когда это происходит, это происходит не из-за конфликтов с другими разработчиками, а из-за конфликтов с ожидающими локальными изменениями. Локальное состояние нужно будет стабилизировать с помощью git stash, git checkout, git commit или git reset. Ошибка слияния при запуске выведет следующее сообщение об ошибке:

Git не работает во время слияния

Сбой ВО ВРЕМЯ слияния указывает на конфликт между текущей локальной ветвью и объединяемой ветвью. Это указывает на конфликт с кодом другого разработчика. Git сделает все возможное, чтобы объединить файлы, но оставит конфликтующие файлы на ваше усмотрение. При сбое в середине слияния выводится следующее сообщение об ошибке:

Создание конфликта слияния

Чтобы по-настоящему ознакомиться с конфликтами слияния, в следующем разделе будет смоделирован конфликт для последующего изучения и разрешения. В примере будет использоваться Unix-подобный интерфейс командной строки Git для выполнения примера моделирования.

В этом примере кода выполняется последовательность команд, которые выполняют следующие действия.

Создайте новый каталог с именем git-merge-test, перейдите в этот каталог и инициализируйте его как новый репозиторий Git.
Создайте новый текстовый файл merge.txt с некоторым содержимым.
Добавьте файл merge.txt в репозиторий и зафиксируйте его.

Теперь у нас есть новый репозиторий с одной основной веткой и файлом merge.txt с содержимым. Далее мы создадим новую ветку для использования в качестве конфликтующего слияния.

Продолжающаяся последовательность команд обеспечивает следующее:

создать и проверить новую ветку с именем new_branch_to_merge_later
перезаписать содержимое файла merge.txt
зафиксировать новый контент

В этой новой ветке: new_branch_to_merge_later мы создали фиксацию, которая переопределяет содержимое файла merge.txt

Эта цепочка команд проверяет основную ветвь, добавляет содержимое в файл merge.txt и фиксирует его. Теперь это переводит наш пример репозитория в состояние, когда у нас есть 2 новых коммита. Один в основной ветке и один в ветке new_branch_to_merge_later. А пока давайте git объединим new_branch_to_merge_later и посмотрим, что получится!

БУМ 💥. Появляется конфликт. Спасибо, Git, что сообщили нам об этом!

Как выявить конфликты слияния

Как видно из предыдущего примера, Git выдаст некоторый описательный вывод, информирующий нас о возникновении КОНФЛИКТА. Мы можем получить дополнительную информацию, выполнив команду git status

Выходные данные git status указывают на наличие неслитых путей из-за конфликта. Файл merge.text теперь отображается в измененном состоянии. Давайте изучим файл и посмотрим, что изменилось.

Здесь мы использовали команду cat для вывода содержимого файла merge.txt. Мы можем увидеть некоторые странные новые дополнения

Думайте об этих новых линиях как о "разделителях конфликта". Строка ======= является «центром» конфликта. Весь контент между центром и строкой — это контент, существующий в текущей ветке main, на которую указывает ссылка HEAD.Альтернативно, весь контент между центром и >>>>>>> new_branch_to_merge_later является контентом, присутствующим в нашей объединяющейся ветке.

Как разрешать конфликты слияния с помощью командной строки

Самый прямой способ разрешить конфликт слияния — отредактировать конфликтующий файл. Откройте файл merge.txt в вашем любимом редакторе. Для нашего примера давайте просто удалим все конфликтные разделители. После этого измененное содержимое файла merge.txt должно выглядеть следующим образом:

После редактирования файла используйте git add merge.txt для подготовки нового объединенного содержимого. Чтобы завершить слияние, создайте новую фиксацию, выполнив:

Git увидит, что конфликт разрешен, и создаст новую фиксацию слияния, чтобы завершить слияние.

Команды Git, которые могут помочь разрешить конфликты слияния

Общие инструменты

Команда status часто используется при работе с Git и во время слияния помогает выявить конфликтующие файлы.

Передача аргумента --merge команде git log создаст журнал со списком коммитов, которые конфликтуют между сливающимися ветвями.

diff помогает находить различия между состояниями репозитория/файлов. Это полезно для прогнозирования и предотвращения конфликтов слияния.

Инструменты, когда git не может начать слияние

checkout можно использовать для отмены изменений в файлах или для изменения ветвей

reset можно использовать для отмены изменений в рабочем каталоге и промежуточной области.

Инструменты для устранения конфликтов git во время слияния

Выполнение git merge с параметром --abort приведет к выходу из процесса слияния и возврату ветки в состояние до начала слияния.

Git reset можно использовать во время конфликта слияния, чтобы сбросить конфликтующие файлы в заведомо хорошее состояние

Обзор

Конфликты слияния могут быть пугающими. К счастью, Git предлагает мощные инструменты для навигации и разрешения конфликтов. Git может обрабатывать большинство слияний самостоятельно с помощью функций автоматического слияния. Конфликт возникает, когда две отдельные ветви внесли изменения в одну и ту же строку в файле или когда файл был удален в одной ветви, но отредактирован в другой. Конфликты, скорее всего, возникнут при работе в команде.

Существует множество инструментов для разрешения конфликтов слияния. В Git есть множество инструментов командной строки, которые мы обсуждали здесь. Для получения более подробной информации об этих инструментах посетите отдельные страницы для git log, git reset, git status, git checkout и git reset. В дополнение к Git многие сторонние инструменты предлагают оптимизированные функции поддержки конфликтов слияния.

Когда я пытаюсь открыть каталог своего проекта в терминале, я вижу следующую ошибку:

Почему git говорит: "Извлечение невозможно, так как у вас есть неслитые файлы" и как мне решить эту проблему?

Этот вопрос помечен тегом git git-pull merge-conflict-resolution git-fetch

~ Вопрос задан 2014-10-15 07:28:00

11 ответов

В настоящее время у вас есть определенный набор файлов, которые вы пытались объединить ранее, но они вызвали конфликты слияния. В идеале, если возникает конфликт слияния, он должен разрешить их вручную и зафиксировать изменения с помощью git add file.name && git commit -m "удалены конфликты слияния" . Теперь другой пользователь обновил рассматриваемые файлы в своем репозитории и отправил свои изменения в общий репозиторий основной ветки.

Так случилось, что ваши конфликты слияния из (вероятно) последнего коммита не были разрешены, поэтому ваши файлы не слились в порядке, и, следовательно, флаг U ( unmerged ) для файлов. Итак, теперь, когда вы делаете git pull , git выдает ошибку, потому что у вас есть какая-то версия файла, которая не разрешена правильно.

Чтобы решить эту проблему, вам нужно будет разрешить конфликты слияния, а также добавить и зафиксировать изменения, прежде чем вы сможете выполнить git pull .

Образец воспроизведения и решение проблемы:

Сначала создадим структуру репозитория

Теперь мы находимся в repo_clone, и если вы сделаете git pull , это вызовет конфликты

Если мы проигнорируем конфликты в клоне и сделаем больше коммитов в исходном репозитории сейчас,

Затем мы делаем git pull и получаем

Обратите внимание, что файл теперь находится в неслитном состоянии, и если мы выполним git status , мы ясно увидим то же самое:

Итак, чтобы решить эту проблему, нам сначала нужно разрешить конфликт слияния, который мы проигнорировали ранее

и установите его содержимое в

а затем добавьте его и зафиксируйте изменения

~ Отвечено 28.11.2014 10:51:44

Вы пытаетесь добавить еще одну новую фиксацию в свою локальную ветку, пока ваш рабочий каталог не очищен. В результате Git отказывается делать это. Рассмотрите следующие диаграммы, чтобы лучше представить сценарий:

удаленный: A
локальный: A
(*указывает, что у вас есть несколько файлов, которые были изменены, но не зафиксированы.)

Есть два варианта действий в этой ситуации. Вы можете либо отменить изменения в своих файлах, либо сохранить их.

Первый вариант: отменить изменения
Вы можете либо использовать git checkout для каждого неслитого файла, либо использовать git reset --hard HEAD, чтобы сбросить все файлы в вашей ветке до HEAD. Кстати, HEAD в вашей локальной ветке — это B, без звездочки. Если вы выберете этот вариант, диаграмма станет:

Теперь, когда вы вытягиваете, вы можете быстро перемотать свою ветку вперед с изменениями из мастера. После извлечения ваша ветка будет выглядеть как master:

Вариант второй: сохранить изменения.
Если вы хотите сохранить изменения, вам сначала нужно разрешить все конфликты слияния в каждом из файлов. Вы можете открыть каждый файл в своей среде IDE и найти следующие символы:

Git предлагает вам две версии кода. Код, содержащийся в маркерах HEAD, является версией вашей текущей локальной ветки. Другая версия исходит из пульта. После того, как вы выбрали версию кода (и удалили другой код вместе с маркерами), вы можете добавить каждый файл в свою промежуточную область, набрав git add . Последний шаг — зафиксировать результат, набрав git commit -m с соответствующим сообщением. На данный момент наша диаграмма выглядит так:

Здесь я пометил коммит, который мы только что сделали, как C', потому что он отличается от коммита C на удаленном компьютере. Теперь, если вы попытаетесь потянуть, вы получите ошибку без быстрой перемотки вперед. Git не может воспроизвести изменения в удаленном в вашей ветке, потому что и ваша ветка, и удаленный отошли от общего коммита-предка B. На этом этапе, если вы хотите вытащить, вы можете либо выполнить еще один git merge , либо git перебазировать свою ветку на пульт.

Чтобы освоить Git, необходимо понимать однонаправленные связанные списки и управлять ими. Я надеюсь, что это объяснение заставит вас задуматься об использовании Git в правильном направлении.

Конфликт слияния — это не конец света. На самом деле, если помнить о нескольких вещах, решать конфликты очень просто:

Шпаргалка Git

Не нужно запоминать все эти команды и параметры: получите нашу популярную «Шпаргалку по Git» — бесплатно!

(1) Сохраняйте спокойствие

Прежде всего, вам нужно понять, что вы не можете ничего сломать: Git всегда позволяет вам вернуться в состояние до возникновения конфликта. С помощью простого «git merge --abort» вы всегда можете отменить слияние и начать заново. Это делает практически невозможным серьезные ошибки.

(2) Как узнать, что у меня конфликт?

При вызове "git status" вы увидите специальную категорию Unmerged paths. Все элементы этой категории находятся в состоянии конфликта, и их необходимо устранить:

(3) Понять, когда и почему возникает конфликт

Конфликты возникают, когда один и тот же файл был изменен противоречивым образом. Большинство модификаций не попадают в эту категорию: если два человека просто работают над одним и тем же файлом, Git, скорее всего, сможет разобраться во всем сам.
Самая распространенная ситуация, когда он не может этого сделать, — это когда в этом файле редактировались одни и те же строки. В этом случае Git не сможет узнать, что правильно — вам придется просмотреть изменения и решить, как вы хотите, чтобы файл в конечном итоге выглядел.

(4) Конфликт — это просто аннотация

Это помогает понять, что в конфликте нет ничего волшебного. В соответствующем файле Git просто помечает области, которые были отредактированы противоречивым образом:

Это поможет вам понять, какие изменения были внесены и даже в какие ветки.

(5) Решение означает выбор и редактирование

Теперь ваша задача состоит в том, чтобы привести файл в желаемое состояние. Есть несколько способов сделать это:

(a) Вы можете просто открыть файл в редакторе, найти маркеры конфликта (см. изображение выше) и внести необходимые изменения. Когда вы закончите, файл должен выглядеть именно так, как вы хотите.
(b) В качестве альтернативы вы можете указать Git, что просто выберете одну из отредактированных версий, называемую «нашей» или «ихней».

Обратите внимание, что существует множество специальных приложений "Инструмент слияния", которые помогут вам в этом процессе. Особенно в сложных ситуациях с несколькими конфликтами в одном и том же файле хороший инструмент может иметь огромное значение. Мы составили список инструментов слияния в нашей бесплатной электронной книге.

(6) Подведение итогов

Когда вы успешно разрешили все конфликты, вам нужно сделать еще две вещи:

(1) Отметить каждый конфликтующий файл как разрешенный. Простой «git add» сделает это за вас.
(2) Зафиксируйте разрешение так же, как и любое другое изменение с помощью команды "git commit".

Решение конфликтов в Tower

Если вы используете клиент Tower Git, его визуальный мастер конфликтов поможет вам легче разрешать конфликты слияния:

Подробнее

Прочитайте главу «Устранение конфликтов слияния» в нашей бесплатной онлайн-книге.
Часто задаваемые вопросы о Git и управлении версиями

Получите нашу популярную памятку по Git бесплатно!

Самые важные команды вы найдете на лицевой стороне, а полезные советы — на обратной. Более 100 000 разработчиков скачали его, чтобы сделать Git немного проще.

О нас

Как создатели Tower, лучшего клиента Git для Mac и Windows, мы помогаем более чем 100 000 пользователей в таких компаниях, как Apple, Google, Amazon, Twitter и Ebay, получить максимальную отдачу от Git.

Как и в случае с Tower, наша миссия с этой платформой – помочь людям стать лучшими профессионалами.

Вот почему мы бесплатно предоставляем наши руководства, видеоролики и памятки (об управлении версиями в Git и многих других темах).

Вы можете разрешать конфликты слияния с помощью командной строки и текстового редактора.

Конфликты слияния возникают, когда в одну и ту же строку файла вносятся конкурирующие изменения или когда один человек редактирует файл, а другой удаляет тот же файл. Дополнительные сведения см. в разделе «О конфликтах слияния».

Совет. Вы можете использовать редактор конфликтов на GitHub для разрешения конкурирующих конфликтов слияния изменений строк между ветвями, которые являются частью запроса на вытягивание. Дополнительные сведения см. в разделе «Разрешение конфликта слияния на GitHub».

Конфликты слияния изменений конкурирующих строк

Чтобы разрешить конфликт слияния, вызванный конкурирующими изменениями строк, вы должны выбрать, какие изменения из разных ветвей включить в новую фиксацию.

Например, если вы и другой человек редактировали файл styleguide.md в одних и тех же строках в разных ветвях одного и того же репозитория Git, вы получите ошибку конфликта слияния при попытке объединить эти ветки. Вы должны разрешить этот конфликт слияния с помощью новой фиксации, прежде чем сможете объединить эти ветки.

Открыть Терминал Терминал Git Bash.

Перейдите в локальный репозиторий Git, в котором есть конфликт слияния.

Создайте список файлов, затронутых конфликтом слияния. В этом примере файл styleguide.md имеет конфликт слияния.

Откройте свой любимый текстовый редактор, например Atom, и перейдите к файлу, в котором есть конфликты слияния.

Чтобы увидеть начало конфликта слияния в вашем файле, найдите в файле маркер конфликта >>>>>> BRANCH-NAME . В этом примере один человек написал «открыть вопрос» в базовой или ветке HEAD, а другой человек написал «задать свой вопрос в IRC» в ветке сравнения или ветке-a.

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

Добавьте или подготовьте свои изменения.

Зафиксируйте свои изменения с помощью комментария.

Теперь вы можете объединить ветки в командной строке или отправить свои изменения в удаленный репозиторий на GitHub и объединить свои изменения в запросе на вытягивание.

Удалены конфликты слияния файлов

Чтобы разрешить конфликт слияния, вызванный конкурирующими изменениями в файле, когда один человек удаляет файл в одной ветви, а другой человек редактирует тот же файл, вы должны выбрать, следует ли удалить или сохранить удаленный файл в новой фиксации.< /p>

Например, если вы редактировали файл, такой как README.md, а другой человек удалил тот же файл в другой ветке того же репозитория Git, вы получите сообщение об ошибке конфликта слияния, когда вы пытаетесь слить эти ветки. Вы должны разрешить этот конфликт слияния с помощью новой фиксации, прежде чем сможете объединить эти ветки.

Открыть Терминал Терминал Git Bash.

Перейдите в локальный репозиторий Git, в котором есть конфликт слияния.

Создайте список файлов, затронутых конфликтом слияния. В этом примере файл README.md имеет конфликт слияния.

Откройте свой любимый текстовый редактор, например Atom, и перейдите к файлу, в котором есть конфликты слияния.

Решите, хотите ли вы сохранить удаленный файл. Вы можете просмотреть последние изменения, внесенные в удаленный файл, в текстовом редакторе.

Чтобы добавить удаленный файл обратно в репозиторий:

Чтобы удалить этот файл из вашего репозитория:

Зафиксируйте свои изменения с помощью комментария.

Есть 2 причины, по которым git merge (или git pull, то есть git fetch, а затем git merge) могут не работать:

Git может не начать слияние

Это происходит потому, что git знает, что в вашем рабочем каталоге или в промежуточной области есть изменения, которые могут быть перезаписаны объединяемыми файлами. Если это произойдет, в отдельных файлах не будет конфликтов слияния.Вам нужно изменить или спрятать файлы, которые он перечисляет, а затем попытаться снова выполнить git pull. Сообщения об ошибках следующие:

Git может дать сбой во время слияния

Это происходит из-за того, что вы зафиксировали изменения, которые конфликтуют с чужими зафиксированными изменениями. Git сделает все возможное, чтобы объединить файлы, и оставит вам проблемы, которые нужно решить вручную в файлах, которые он перечисляет. Сообщение об ошибке выглядит следующим образом:

Распространенные вопросы, возникающие при сбое git во время слияния

Как узнать, в каких файлах есть конфликты?

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

"Изменения, которые необходимо зафиксировать": все зафиксированные изменения в файлах, не затронутых конфликтом, являются промежуточными.

"Изменено, но не обновлено. Не объединено": все файлы, имеющие конфликты, которые необходимо разрешить, прежде чем репозиторий вернется в рабочее состояние.

Как найти конфликты внутри самого файла?

Конфликты отмечены в файле четкими разрывами строк:

=======: указывает точку останова, используемую для сравнения. Разбивает изменения, зафиксированные пользователем (выше), на изменения, полученные в результате слияния (ниже), чтобы визуально увидеть различия.

>>>>>>>: указывает на конец строк, в которых возник конфликт слияния.

Как разрешить конфликт слияния в файле?

Вы разрешаете конфликт, редактируя файл, чтобы вручную объединить части файла, которые не удалось объединить git. Это может означать отказ от ваших изменений или чужих изменений или их сочетание. Вам также потребуется удалить '>>>>>>' в файле.

Что мне делать после разрешения конфликтов во всех затронутых файлах?

git добавить файл(ы), git commit и git push (Push только для отслеживаемых веток.)

(Примечание добавлено Чином: необходимо зафиксировать все, а не только разрешенный конфликтный файл.)

Инструменты, помогающие разрешить оба типа конфликтов слияния

Следующие ниже инструменты git помогут вам решить как простые, так и более сложные слияния git.

Общие инструменты

отличить git

git diff: команда, помогающая находить различия между состояниями репозитория/файлов. Полезно для прогнозирования и предотвращения конфликтов слияния.

git diff origin/master : найти различия между текущим индексом (HEAD) файла fileName и тем, что находится в центральном репозитории (origin/msater)

Изменения, поступающие из источника/мастера, помечаются знаком +, а изменения в локальном репозитории (HEAD) помечаются знаком -. Этот синтаксис не уведомляет о том, какие строки удаляются, а только о том, какие строки происходят в каком состоянии файла.

git diff FETCH_HEAD : предоставит тот же вывод, что и выше, за исключением того, что он ограничен индексом последней выборки, которую сделал пользователь. Возможно, это не последняя версия в центральном репозитории.

статус git

git status: команда предоставляет обзор всех файлов, которые были изменены и находятся в конфликте во время слияния.

"Изменения, которые необходимо зафиксировать": все изменения в файлах, не затронутые конфликтом, являются промежуточными.

"Изменено, но не обновлено. Не объединено": все файлы с конфликтами, которые необходимо разрешить, прежде чем репозиторий вернется в рабочее состояние.

Инструменты, специально предназначенные для случаев, когда git отказывается начинать слияние

запас git

ВАЖНО: не используйте git stash, если git прошел слияние и возникли конфликты слияния! Используйте git stash только в том случае, если git отказался от слияния, потому что он предвидит конфликты.

git stash: скрывает любые изменения в рабочей области и рабочем каталоге. Эта команда полезна для сохранения всех изменений, которые не готовы к фиксации, и пользователь хочет иметь обновленный репозиторий.

git stash save "": Сохранение изменений в файлах в рабочем каталоге и промежуточной области, о которых знает git

git stash pop: удаляет самый последний тайник или любой указанный тайник и применяет изменения как слияние. Если слияние не удается, тайник не удаляется из списка и должен быть удален вручную.

оформить заказ через git

git checkout : может использоваться для удаления изменений в рабочем каталоге, чтобы разрешить git pull.

git reset --mixed

git reset --mixed: можно использовать для удаления файлов из стадии, чтобы разрешить git pull.

Инструменты, специально предназначенные для случаев возникновения конфликтов git во время слияния

git reset

git reset --hard: сбросить репозиторий, чтобы выйти из ситуации конфликта слияния. git reset, особенно с опцией --hard, можно использовать для отмены конфликта слияния (нажмите здесь для получения дополнительной информации).

ВАЖНО: не используйте какие-либо другие параметры, кроме --hard, для сброса при разрешении ситуации, когда git не удалось выполнить слияние, так как они оставят маркеры строк конфликта в файле, и вы можете в конечном итоге зафиксировать файлы с маркерами конфликта. .

Читайте также: