Git error path is unmerged

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

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

Общие сведения о конфликтах слияния

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

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

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

Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.

Git прерывает работу в самом начале слияния

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

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

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

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

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

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

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

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

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

• Создает новую ветку с именем new_branch_to_merge_later и выполняет переход в нее.
• Перезаписывает содержимое файла merge.txt .
• Выполняет коммит нового содержимого.

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

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

БАХ! 💥 Возник конфликт. Хорошо, что система Git сообщила нам об этом.

Выявление конфликтов слияния

Как мы убедились на выполняемом примере, Git выводит небольшое описательное сообщение о возникновении КОНФЛИКТА. Чтобы получить более глубокое понимание проблемы, можно запустить команду git status .

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

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

Эти новые строки можно рассматривать как «разделители конфликта». Строка ======= является «центром» конфликта. Все содержимое между этим центром и строкой находится в текущей ветке 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 . Помимо этого многие сторонние инструменты также предлагают оптимизированные функции, поддерживающие работу с конфликтами слияния.

Готовы попробовать ветвление?

Ознакомьтесь с этим интерактивным обучающим руководством.

Источник

How to resolve git status «Unmerged paths:»?

I merged branch dog into animal . When I go to commit, I get the following:

I had different directory names and file names in each branch. The animal branch has the changes that I want.

When I go to reset the head, it doesn’t work. And when I go to take any other git action (remove, checkout, etc), I get a path not found error.

What commands do I need to execute to resolve this?

2 Answers 2

All you should need to do is:

Another way of dealing with this situation if your files ARE already checked in, and your files have been merged (but not committed, so the merge conflicts are inserted into the file) is to run:

This will switch to HEAD, and tell git to forget any merge conflicts, and leave the working directory as is. Then you can edit the files in question (search for the «Updated upstream» notices). Once you’ve dealt with the conflicts, you can run

which will allow you to interactively select which changes you want to add to the index. Once the index looks good ( git diff —cached ), you can commit, and then

to destroy all the unwanted changes in your working directory.

Источник

Git: can’t undo local changes (error: path . is unmerged)

I have following working tree state

File foo/bar.txt is there and I want to get it to the «unchanged state» again (similar to ‘svn revert’):

Now it is getting confusing:

The same file in both sections, new and modified? What should I do?

8 Answers 8

You did it the wrong way around. You are meant to reset first, to unstage the file, then checkout, to revert local changes.

This worked perfectly for me:

// Note dot (.) at the end. And all will be good

In recent git versions, git restore is supposed to be a «better» way to revert undesired local changes than the overloaded checkout . Great, that sounds reasonable — a nice simple purpose-built tool for a common operation.

But, here’s my new «favorite» git bug. Yes, I know some git-head is going to say, «It’s not a bug, it’s by design». But with this kind of user interface, I stand by the «bug» moniker:

(brought to you by git 2.25.1)

First the minor issue: when a tool refuses to do something because of a particular condition, it’s not just a warning. At least it should say the operation was not performed. Now I have to go investigate whether the operation was actually performed or not (hint: it wasn’t).

The second issue, of course, is obvious. Now, let’s look at the man page entry to see why this fantastic tool won’t do what I am telling it to do:

Holy smokes! I guess the git-ish fix for the user interface problem here will be to rename the option from —ignore-unmerged to —ignore-unmerged-except-in-cases-where-we-do-not-want-to-allow-that—consult-documentation-then-source-code-then-team-of-gurus-when-you-cannot-figure-it-out—and-wait-while-half-of-them-argue-about-why-it-is-right-as-is-while-the-other-half-advocate-adding-four-more-options-as-the-fix .

Then go to the community to find out a fix. I dare you.

Obviously, I didn’t have my refs in a state where the tree-ish blobs could be resolved with the commit-ishes from working file to staging area. err index?

Источник

Cannot checkout, file is unmerged

I am trying to remove the file from my working directory but after using the following command

I got the following error message

What is that and how to resolve it?

Following is my git status

9 Answers 9

If you want to discard modifications you made to the file, you can do:

To remove tracked files (first_file.txt) from git:

And to remove untracked files, use:

Following worked for me

I was getting the bellow error

status tell you what to do.

you probably applied a stash or something else that cause a conflict.

either add, reset, or rm.

I don’t think execute

when git notice your files is unmerged, you should ensure you had committed it.

And then open the conflict file:

fix the conflict

it should works for you.

In my case, I found that I need the -f option. Such as the following:

to get rid of the «needs merge» error.

i resolved by doing below 2 easy steps :

step 1: git reset Head step 2: git add .

It works for me.

It will recover file from curreny HEAD

Linked

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Git Troubleshooting

Automatic merge failed; fix conflicts and then commit the result.

I was faced with “a merge conflict”, and managed to troubleshoote it. Following commands are what I typed right before the conflict.

I tried to troubleshoot it as I refered a following page.

“Resolving a merge conflict using the command line”

Resolving a merge conflict using the command line — GitHub Help

Tip: You can use the conflict editor on GitHub to resolve competing line change merge conflicts between branches that…

1st step is to see the files affected by the merge conflict.

This target file is, for convenience, set the font style as bold and as italic.

If you would like to see for more details, type “git diff”.

Changes are shown after the line .

======= divides your changes from the changes in the other branch, followed by >>>>>>> BRANCH-NAME .

To see the beginning of the merge conflict in your file, search the file for the conflict marker . When you open the file in your text editor, you’ll see the changes from the HEAD or base branch after the line . Next, you’ll see ======= , which divides your changes from the changes in the other branch, followed by >>>>>>> BRANCH-NAME . In this example, one person wrote «open an issue» in the base or HEAD branch and another person wrote «ask your question in IRC» in the compare branch or branch-a .

If you have questions, please
>>>>>> branch-a

Secondly, edit the file that has merge conflicts.

Whichever you would prefer. If you delete , ======= and >>>>>>> BRANCH-NAME are deleted automatically.

After I finished editing the file, I tried to merge.

“Resolving a merge conflict using the command line”

Источник

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

Общие сведения о конфликтах слияния

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

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

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

Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.

Git прерывает работу в самом начале слияния

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

error: Entry '<fileName>' not uptodate. Cannot merge. (Changes in working directory)

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

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

error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (Changes in staging area)

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

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

$ mkdir git-merge-test
$ cd git-merge-test
$ git init .
$ echo "this is some content to mess with" > merge.txt
$ git add merge.txt
$ git commit -am"we are commiting the inital content"
[main (root-commit) d48e74c] we are commiting the inital content
1 file changed, 1 insertion(+)
create mode 100644 merge.txt

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

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

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

$ git checkout -b new_branch_to_merge_later
$ echo "totally different content to merge later" > merge.txt
$ git commit -am"edited the content of merge.txt to cause a conflict"
[new_branch_to_merge_later 6282319] edited the content of merge.txt to cause a conflict
1 file changed, 1 insertion(+), 1 deletion(-)

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

• Создает новую ветку с именем new_branch_to_merge_later и выполняет переход в нее.
• Перезаписывает содержимое файла merge.txt.
• Выполняет коммит нового содержимого.

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

git checkout main
Switched to branch 'main'
echo "content to append" >> merge.txt
git commit -am"appended content to merge.txt"
[main 24fbe3c] appended content to merge.tx
1 file changed, 1 insertion(+)

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

$ git merge new_branch_to_merge_later
Auto-merging merge.txt
CONFLICT (content): Merge conflict in merge.txt
Automatic merge failed; fix conflicts and then commit the result.

БАХ! 💥 Возник конфликт. Хорошо, что система Git сообщила нам об этом.

Выявление конфликтов слияния

Как мы убедились на выполняемом примере, Git выводит небольшое описательное сообщение о возникновении КОНФЛИКТА. Чтобы получить более глубокое понимание проблемы, можно запустить команду git status.

$ git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   merge.txt

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

$ cat merge.txt
<<<<<<< HEAD
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_later

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

• <<<<<<< HEAD
• =======
• >>>>>>> new_branch_to_merge_later

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

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

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

this is some content to mess with
content to append
totally different content to merge later

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

git commit -m "merged and resolved the conflict in 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. Помимо этого многие сторонние инструменты также предлагают оптимизированные функции, поддерживающие работу с конфликтами слияния.

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

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

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

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

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

1. Откройте ТерминалТерминалGIT Bash.

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

   cd REPOSITORY-NAME

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

   $ git status
   > # On branch branch-b
   > # You have unmerged paths.
   > #   (fix conflicts and run "git commit")
   > #
   > # Unmerged paths:
   > #   (use "git add ..." to mark resolution)
   > #
   > # both modified:      styleguide.md
   > #
   > no changes added to commit (use "git add" and/or "git commit -a")

4. Откройте избранный текстовый редактор, например Visual Studio Code, и перейдите к файлу с конфликтами слияния.

5. Чтобы увидеть начало конфликта слияния в файле, выполните в нем поиск метки конфликта <<<<<<<. При открытии файла в текстовом редакторе вы увидите изменения из ГЛАВНОЙ или базовой ветви после строки <<<<<<< HEAD. Далее вы увидите =======, который отделяет ваши изменения от изменений в другой ветви, а затем >>>>>>> BRANCH-NAME. В этом примере один человек написал «открыть проблему» в базовой или ГЛАВНОЙ ветви, а другой написал «задать свой вопрос в IRC» в ветви сравнения или branch-a.

   If you have questions, please
   <<<<<<< HEAD
   open an issue
   =======
   ask your question in IRC.
   >>>>>>> branch-a
   

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

   If you have questions, please open an issue or ask in our IRC channel if it's more urgent.

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

   $ git add .

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

   $ git commit -m "Resolved merge conflict by incorporating both suggestions."

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

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

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

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

1. Откройте ТерминалТерминалGIT Bash.

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

   cd REPOSITORY-NAME

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

   $ git status
   > # On branch main
   > # Your branch and 'origin/main' have diverged,
   > # and have 1 and 2 different commits each, respectively.
   > #  (use "git pull" to merge the remote branch into yours)
   > # You have unmerged paths.
   > #  (fix conflicts and run "git commit")
   > #
   > # Unmerged paths:
   > #  (use "git add/rm ..." as appropriate to mark resolution)
   > #
   > #   deleted by us:   README.md
   > #
   > # no changes added to commit (use "git add" and/or "git commit -a")

4. Откройте избранный текстовый редактор, например Visual Studio Code, и перейдите к файлу с конфликтами слияния.

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

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

   $ git add README.md

   Чтобы удалить этот файл из репозитория, выполните следующие действия:

   $ git rm README.md
    > README.md: needs merge
    > rm 'README.md'

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

   $ git commit -m "Resolved merge conflict by keeping README.md file."
   > [branch-d 6f89e49] Merge branch 'branch-c' into branch-d

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

Дополнительные материалы

• Сведения о конфликтах слияния
• Локальное получение для изменения запросов на вытягивание

A merge conflict is not the end of the world. Actually, if you keep a couple of things in mind, solving conflicts is easy as pie:

(1) Keep Calm

Above all, you need to realize that you cannot break anything: Git always allows you to go back to the state before the conflict occurred. With a simple «git merge —abort«, you can always undo the merge and start over again. This makes it almost impossible to severely screw things up.

(2) How do I Know I Have a Conflict?

When calling «git status», you’ll see a special Unmerged paths category. All of the items in this category are in a conflict state and need to be dealt with:

$ git status
# On branch contact-form
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#       both modified:   contact.html
#
no changes added to commit (use "git add" and/or "git commit -a")

(3) Understand When & Why a Conflict Happens

Conflicts occur when the same file was changed in contradictory ways. Most modifications don’t fall into this category: if two people just work on the same file, Git can most likely figure things out on its own.
The most common situation when it cannot do this is when the exact same lines were edited in that file. In that case, Git has no way of knowing what’s correct — you’ll have to look at the changes and decide how you want the file to finally look.

(4) A Conflict is Just an Annotation

It helps to realize that a conflict is nothing magical. In the concerned file, Git simply marks the areas that were edited in contradictory ways:

This helps you understand which edits were made — and even on which branches.

(5) Solving Means Choosing & Editing

Your job now is to condition the file to its desired state. There are a couple of ways to do this:

(a) You can simply open the file in an editor, search for the conflict markers (see above image) and make any necessary modifications. When you’re done, the file needs to look exactly as you want it to look.
(b) Alternatively, you can tell Git that you’ll simply go with one of the edited versions, called «ours» or «theirs».

git checkout --ours path/to/conflict-file.css

Note that there are lots of dedicated «Merge Tool» applications that help you with this process. Especially in complex situations with multiple conflicts in the same file, a good tool can be of tremendous value. We’ve compiled a list of merge tools in our free ebook.

(6) Wrap Up

When you’ve successfully solved all conflicts, you need to do two more things:

(1) Mark each conflicted file as solved. A simple «git add <filepath>» does this for you.
(2) Commit the resolution just as you would commit any other change with the «git commit» command.

Solving Conflicts in Tower

In case you are using the Tower Git client, its visual Conflict Wizard will help you solve merge conflicts more easily:

Learn More

• Check out the chapter Dealing with Merge Conflicts in our free online book
• More frequently asked questions about Git & version control

Git is the standard source code repository manager for open source projects and many closed source projects. This article shows new Git users how to do something slightly advanced but fundamental to its purpose: resolving a git-merge conflict.

What is a git merge?

All modern source-control systems have an essential feature: the ability for multiple developers to work on the same project, at the same time, without interfering with each other. Git implements this feature by allowing multiple developers to work on a branch locally, then push their code to a central place. Then, others can pull the code back to their local copy and continue their own work with their collaborators’ changes in place.

When you want to bring the changes in a branch into your current branch, you use a git merge command. The merge takes all the changes in the other branch and applies them to the current branch.

What is a merge conflict?

In every situation where work can be parallelized, work will eventually overlap. Sometimes two developers will change the same line of code in two different ways; in such a case, Git can’t tell which version is correct—that’s something only a developer can decide.

If this happens, a developer will see the following error during a git merge:

Auto-merging [filename1]
CONFLICT (content): Merge conflict in [filename1]
Automatic merge failed; fix conflicts and then commit the result.

Resolving merge conflicts can take a minute or they can take days (if there are a lot of files that need to be fixed). It’s recommended, and good coding practice, to sync your code multiple times a day by committing, pushing, pulling, and merging often.

How do you resolve a git merge conflict?

Git gives a clue to resolving conflicts in its error message. It says Merge conflict in [filename1], so you know there is a problem with that file. Then it says fix conflicts and then commit the result, so if you follow directions, edit the file, then commit it, everything should work fine. Let’s see this in action.

Create a new Git repo, add a file, make a branch, make some conflicting edits, and see what it looks like.

Start with an empty directory and run git init:

$ ls -l
$ git init
Initialized empty Git repository in /home/bob/example/.git/
$

Now create a README file and commit the changes:

$ echo "This is a new README file" > README.md
$ cat README.md
This is a new README file
$ git add README.md
$ git commit -m "README file added"
1 file changed, 1 insertion(+)
create mode 100644 README.md
$ git status
On branch master
nothing to commit, working tree clean
$

Create a new branch:

$ git checkout -b "branch_to_create_merge_conflict"
Switched to a new branch 'branch_to_create_merge_conflict'

On the new branch:

$ git branch
* branch_to_create_merge_conflict
master

Make an edit:

This is a new README file

This is an edit on the branch

Now commit that edit:

$ vim README.md
$ git add README.md
$ git commit -m "Edits made to README on the branch"
[branch_to_create_merge_conflict 9c5e88a] Edits made to README on the branch
1 file changed, 2 insertions(+)

Return to the master branch, edit the README on line 3 with something different, and commit that.

Change to the master branch:

$ git checkout master
Switched to branch 'master'

Edit the README:

This is a new README file

This is an edit on the master branch

Commit the edit:

$ git add README.md
$ git commit -m "Edits made to README on the master branch"
[master 7ea2985] Edits made to README on the master branch
1 file changed, 2 insertions(+)

Merge the branch into master to see the error:

$ git branch
  branch_to_create_merge_conflict
* master
$ git merge branch_to_create_merge_conflict
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Now, go into the README file, as Git asks, to see what it looks like:

This is a new README file

<<<<<<< HEAD
This is an edit on the master branch
=======	
This is an edit on the branch
>>>>>>> branch_to_create_merge_conflict

As you can see, Git added some syntax including seven «less than» characters, <<<<<<< and seven «greater than» characters, >>>>>>>, separated by seven equal signs, =======. These can be searched using your editor to quickly find where edits need to be made.

That there are two sections within this block:

• The «less than» characters denote the current branch’s edits (in this case, «HEAD,» which is another word for your current branch), and the equal signs denote the end of the first section.
• The second section is where the edits are from the attempted merge; it starts with the equal signs and ends with the «greater than» signs.

As a developer, you decide what stays and what goes. Make your edits as necessary, then close the file:

This is a new README file

This is an edit on the branch

As you can see, this keeps the branch’s edits. You can run git status to see further instructions:

$ vim README.md
$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add ..." to mark resolution)
  both modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")

Notice that if you run into serious issues, you can abort the merge by running git merge —abort to abort the merge.

Follow the directions to add the file and then commit:

$ git add README.md
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)

Changes to be committed:
modified: README.md

$ git commit
[master 9937ca4] Merge branch 'branch_to_create_merge_conflict'

Key takeaways and further reading

Merge conflicts are going to happen on teams of any size, given enough time. It’s important to be able to resolve them with a clear head. As a developer, I’ve been quite overwhelmed staring at a 10+ file merge-conflict problem. Understanding what you are looking at when you get a merge conflict goes a long way.

I didn’t cover merge conflicts in the context of an integrated development environment. Knowing how to use the Git command-line tool, including fixing merge conflicts, is indispensable to understanding Git and being able to work on Git in any environment.

Git’s website and documentation are good resources if you get stuck. You can find advanced information on Git merging, including merge-conflict resolution, in the advanced merging section of the Git Pro book.

This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.