Git для начинающих. Урок 10.
Конфликты и их разрешение
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Работа с конфликтами в командной строке
До этого момента мы или работали в одиночку, или с коллегой над разными участками кода. То есть не пересекались с другими программистами. На практике такое бывает редко, и случается, что приходится править те же участки кода, что и наши коллеги.
Посмотрим на практике
У нас есть блок учеников, он уже в мастере и выглядит так
Нам нужно доработать этот блок, мы создаем новую ветку students-redesign и изменяем этот блок. Мы хотим добавить классы к тегам ul и li. Получается так
Закоммитим эти изменения и будем готовы залить в мастер. Но пока мы работали, нашему коллеге поручили добавить в этот же блок нового ученика. Эту задачу коллега уже сделал и залил в мастер. У него (и в мастере) код блока учеников теперь выглядит так
То есть просто добавил еще один тег li. Конечно, наших изменений он не видел.
Таким образом два человека правили код в одном и том же месте.
Мы переключаемся в мастер, пулимся, подтягиваем его коммит и пытаемся слить ее в мастер. И видим такое
$ git merge students-redesign Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Здесь git говорит, что обнаружен конфликт. То есть в текущей ветки (master) и в той, которую мы пытаемся вмерджить (students-redesign) есть изменения в одних и тех же участках кода. Нужно посмотреть, в чем заключается конфликт. Открываем файл index.html и видим
Угловые скобки ограничивают зону конфликта — те участки, где git видит изменения.
Блок между >>>>>> students-redesign — то, что в ветке students-redesign.
Чтобы не запутаться, git дает подсказки:
— HEAD — это текущая ветка,
— students-redesign — ветка, которую мы сливаем в текущую.
Наша задача — собрать эти 2 участка в одно целое. Добавить и изменения в ветку students-redesign, и те, что уже приехали в мастер. Это называется разрешить конфликт или разрезолвить конфликт.
Мы помним, что наши изменения в ветке students-redesign это добавленные классы students (ul) и students__fio (li). Значит, их нужно оставить. А изменения в мастере — это новый ученик, новый тег li, его тоже нужно оставить, но дописать к li класс students__fio, чтобы теги были с одинаковыми классами
Мы оставили новые изменения и учли то, что приехало в мастер. Угловые скобки и значки === тоже нужно убрать — в итоге останется правильный html.
Последнее, что останется сделать, это соощить git, что конфликты разрешены. Для этого нужно закоммтить изменения так, мы привыкли, и не забыть запушить. То есть, коммит с фиксом конфликта — это самый обычный коммит.
$ git add index.html $ git commit -m 'Merge branch students-redesign' $ git push origin master
Как работать с конфликтами в PhpStorm
PhpStorm упрощает работу с конфликтами. Когда мы мерджим ветку и возникает конфликт, PhpStorm показывает окно, в котором выведен список всех файлов, в которых обнаружены конфликты. Кнопка Merge. открывает еще одно окно, разделенное на 3 части. В левой части показываются изменения в текущей ветке, куда мы мерджим. В правой части — изменения из ветки, которую мы мерджим в нашу. А в центре нужно собрать готовый код.
Такое визуальное разделение гораздо проще, чем анализировать сплошной текст с угловыми скобками и разделителями ===
Когда мы разрешим все конфликты, PhpStorm предложит нам нажать кнопку Apply, чтобы закончить мердж. Мы ее нажмем и IDE создаст мердж-коммит без необходимости коммитить вручную, как мы это делали в командной строке.
Мердж мастера в свою ветку
Происходит точно так же, как и нашей ветки в мастер. Конфликты резолвим аналогично. При этом когда придет время сливать ветку в мастер, разрешать конфликты больше не придется, потому что мы уже создали коммит с фиксом конфликта.
Для информации
- конфликты в коде — это не чрезвычайная ситуация, это нормально
- если вы работаете один, возможно, конфликты происходить не будут или будут достаточно редки
- конфликты будут гораздо чаще, если вы работаете в команде
- разрешение конфликтов бывает долгим, иногда очень долгим
Когда я начинал изучать git, конфликты для меня были самой большой проблемой. Каждый раз, когда мерджил ветку в мастер, я со страхом ждал, будет конфликт или нет. Реакция была примерно такая
Возможно, вам тоже сейчас кажется, что это сложная тема. Но со временем начинаешь больше понимать, почему возникают конфликты, когда они возникают и как их разрешать. Конфликты в коде — это вполне рабочая ситуация, это часть работы программиста.
Что могу посоветовать
- пользуйтесь визуальными инструментами для разрешения конфликтов. PhpStorm в этом гораздо удобнее простого редактора и командной строки
- чаще подтягивайте мастер в свою ветку, то есть держите ветку актуальной. Чем больше устаревает ваша ветка, тем больше шансов, что при мердже окажется много конфликтов
- не откладывайте разрешение конфликта. Рано или поздно это придется сделать
- не стесняйтесь звать на помощь. Просто потому, что вы можете не знать детали функционала, который реализовал ваш коллега
- не забывайте пушить ветку после резолва конфликта. Особенно это важно, если вы работаете с коллегой в одной ветке. Тогда при подтягивании мастера конфликт разрешит только один из вас. Остальные подтянут чистый код
- пользуйтесь инструментом «волшебная палочка» в PhpStorm очень осторожно (смотрите видео, там это разбирается)
На этом первая часть курса закончена
Спасибо за внимание и до встречи!
Вторая часть курса в процессе. За обновлениями следите здесь или в группе в ВК
Скоро выйдет промежуточный урок — переходный от первой ко второй части.
Все уроки курса
- Вводный урок
- 1. Установка и базовая настройка git
- 2. Создание и клонирование репозитория git
- 3. Делаем первые изменения, git status и git diff
- 4. Коммиты и история коммитов, git commit, git log и git show
- 5. Подробнее об истории коммитов. Путешествие по истории
- 6. Работа с сервером, git push и git pull
- 7. Ветки — главная фишка git, git branch и git checkout
- 8. Работа с ветками на сервере, git fetch
- 9. Слияния или мерджи веток, git merge
- 10. Конфликты и их разрешение
- Платная часть курса. Презентация
- * 11. Работа с gitignore и git exclude
- * 12. Буфер обмена git, git stash
- * 13. Копирование коммитов, git cherry-pick
- * 14. Отмена и редактирование последнего коммита
- * 15. Отмена произвольного коммита, git revert
- 16. Склеивание коммитов, git rebase —interactive и git reflog
- * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
- * 18. Работа с git rebase. Отличия от merge
- * 19. Что такое git push —force и как с ним работать
- * 20. Ищем баги с помощью git, git bisect
- * 21. Как и зачем работать с тегами git
- * 22. Процессы: github flow и git flow
- * 23. Псевдонимы в git
- 24. Мердж-реквесты
- * 25. Форки
Конфликты слияния в Git
Системы контроля версий предназначены для управления дополнениями, вносимыми в проект множеством распределенных авторов (обычно разработчиков). Иногда один и тот же контент могут редактировать сразу несколько разработчиков. Если разработчик A попытается изменить код, который редактирует разработчик B, может произойти конфликт. Для предотвращения конфликтов разработчики работают в отдельных изолированных ветках. Основная задача команды git merge заключается в слиянии отдельных веток и разрешении любых конфликтующих правок.
Общие сведения о конфликтах слияния
Обычно конфликты возникают, когда два человека изменяют одни и те же строки в файле или один разработчик удаляет файл, который в это время изменяет другой разработчик. В таких случаях Git не может автоматически определить, какое изменение является правильным. Конфликты затрагивают только того разработчика, который выполняет слияние, остальная часть команды о конфликте не знает. Git помечает файл как конфликтующий и останавливает процесс слияния. В этом случае ответственность за разрешение конфликта несут разработчики.
Типы конфликтов слияния
Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.
Git прерывает работу в самом начале слияния
Выполнение команды слияния прерывается в самом начале, если Git обнаруживает изменения в рабочем каталоге или разделе проиндексированных файлов текущего проекта. Git не может выполнить слияние, поскольку иначе эти ожидающие изменения будут перезаписаны новыми коммитами. Такое случается из-за конфликтов не с другими разработчиками, а с ожидающими локальными изменениями. Локальное состояние необходимо стабилизировать с помощью команд git stash , git checkout , git commit или git reset . Если команда слияния прерывается в самом начале, выдается следующее сообщение об ошибке:
error: Entry '' not uptodate. Cannot merge. (Changes in working directory)Git прерывает работу во время слияния
Сбой В ПРОЦЕССЕ слияния говорит о наличии конфликта между текущей локальной веткой и веткой, с которой выполняется слияние. Это свидетельствует о конфликте с кодом другого разработчика. Git сделает все возможное, чтобы объединить файлы, но оставит конфликтующие участки, чтобы вы разрешили их вручную. При сбое во время выполнения слияния выдается следующее сообщение об ошибке:
Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
error: Entry '' 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 . " to mark resolution)
both modified: merge.txtВывод команды git status говорит о том, что из-за конфликта не удалось слить пути. Теперь файл merge.text отображается как измененный. Давайте изучим этот файл и посмотрим, что изменилось.
$ cat merge.txt
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_laterДля просмотра содержимого файла merge.txt воспользуемся командой cat . Видно, что в файле появились новые странные дополнения:
- =======
- >>>>>>> new_branch_to_merge_later
Эти новые строки можно рассматривать как «разделители конфликта». Строка ======= является «центром» конфликта. Все содержимое между этим центром и строкой находится в текущей ветке 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, с помощью которых можно разрешить конфликты слияния
Общие инструменты
git statusКоманда status часто используется во время работы с Git и помогает идентифицировать конфликтующие во время слияния файлы.
git log --mergeПри передаче аргумента —merge для команды git log будет создан журнал со списком конфликтов коммитов между ветками, для которых выполняется слияние.
git diffКоманда diff помогает найти различия между состояниями репозитория/файлов. Она полезна для выявления и предупреждения конфликтов слияния.
Инструменты для случаев, когда Git прерывает работу в самом начале слияния
git checkoutКоманда checkout может использоваться для отмены изменений в файлах или для изменения веток.
git reset --mixedКоманда reset может использоваться для отмены изменений в рабочем каталоге или в разделе проиндексированных файлов.
Инструменты для случаев, когда конфликты Git возникают во время слияния
git merge --abortПри выполнении команды git merge с опцией —abort процесс слияния будет прерван, а ветка вернется к состоянию, в котором она находилась до начала слияния.
git resetКоманду git reset можно использовать для разрешения конфликтов, возникающих во время выполнения слияния, чтобы восстановить заведомо удовлетворительное состояние конфликтующих файлов.
Резюме
Конфликты слияния могут пугать. К счастью, Git предлагает мощные инструменты их поиска и разрешения. Большую часть слияний система Git способна обрабатывать самостоятельно с помощью функций автоматического слияния. Конфликт возникает, когда в двух ветках была изменена одна и та же строка в файле или когда некий файл удален в одной ветке и отредактирован в другой. Как правило, конфликты возникают при работе в команде.
Конфликт слияния можно решить множеством способов. В этой статье мы рассмотрели немалое количество инструментов командной строки, которые доступны в Git. Более подробную информацию о них см. на отдельных страницах для команд git log, git reset, git status, git checkout и git reset. Помимо этого многие сторонние инструменты также предлагают оптимизированные функции, поддерживающие работу с конфликтами слияния.
Безболезненное разрешение Merge конфликтов в Git
Предлагаю читателям «Хабрахабра» перевод публикации «Painless Merge Conflict Resolution in Git»
из блога blog.wuwon.id.au.
В моей повседневной работе, часто приходится иметь дело со множеством git ветвей (branch). Это могут быть ветви промежуточных релизов, ветви с устаревшим API находящиеся на поддержке для некоторых клиентов, или ветви с экспериментальными свойствами. Лёгкость создания ветвей в модели Git так и соблазняет разработчиков создавать все больше и больше ветвей, и как правило бремя от большого количества ветвей становится очень ощутимым, когда приходится все эти ветви поддерживать и периодически делать слияния (merge) с другими ветвями.
Слияния очень важны для поддержания кода в актуальном состоянии, и как правило ошибка сделанная при слиянии может привести к большей головной боли, нежели ошибка сделанная при простом коммите. К сожалению ошибки слияния далеко не редкость, потому что во-первых слияния имеют несколько родительских ветвей. Даже при анализе истории слияния ветвей, бывает очень трудно понять, какие же изменения были сделаны для разрешения конфликта. Во-вторых, отмена неудачного слияния может превратиться в большую головную боль. В-третьих, большая часть конфликтов слияния происходит при работе с чужим кодом, потому что само понятие ветвей подразумевает множество пользователей, т.е. далеко не всегда слияние производит тот же человек который работал с той или иной веткой. В сухом остатке, сделать ошибку при слиянии очень легко, её трудно исправить и трудно найти. Таким образом время потраченное на изучение и понимание процесса слияния ветвей, окупится с лихвой.
Удивительно, но я обнаружил, что многие доступные инструменты и интерфейсы предназначенные для выполнения слияний, не достаточно хорошо оснащены для эффективного выполнения этого процесса. Часто программист просто надеется что команда git merge сделает за него всю работу. Но когда все-таки происходит конфликт, то обычно стратегия слияния заключается в беглом просмотре кода вокруг строки конфликта, и интуитивном угадывании что именно данный кусок кода предпочтительней другого.
В данной статье я надеюсь продемонстрировать что процесс разрешения конфликтов может быть пошагово точным, при котором отпадает необходимость что-либо там угадывать.
Голубые Розы (Roses are Blue)
Давайте предположим что вашей команде поручили писать поэмы в отведённом для этих целей репозитории. (Какой кошмар!) А вам доверили самое главное — делать слияния последних фиксов из ветки master в ветку beta. Итак, вы переключаетесь в ветку beta и выполняете следующую команду:
$ git merge master Auto-merging roses.txt CONFLICT (content): Merge conflict in roses.txt Automatic merge failed; fix conflicts and then commit the result.Ого, это конфликт. Вы решаете просмотреть файл на который ссылается git:
$ cat roses.txt >>>>>> master (Listing 1)Замечательно! Весь файл, как показывает Listing 1, находится в конфликтном состоянии. Какой же вариант файла является более корректным? Оба варианта выглядят корректно. Верхний вариант написан в хакер-стиле с элементами цветовой кодировки в стиле HTML и с использованием только строчных букв. Нижний вариант выглядит более натурально, с использованием пунктуации и заглавных букв.
Если бы это был ваш проект, вы бы могли просто выбрать один вариант и покончить с этим слиянием. Но проблема в том, что это не ваша поэма, вы никогда не читали эту поэму раньше, не были ответственны за написание или редактирование, и вы отлично понимаете что в случае не верного решения чья-то тяжёлая работа может кануть в небытие. Однако вас всё же назначили ответственным по слиянию этих веток. Что же вам делать?
Назад к Базе (Back to Base)
Хитрость заключается в том, что Listing 1 не даёт вам полную информацию, необходимую для совершения корректного слияния. На самом деле, в процессе слияния участвуют четыре важных части информации (состояния), три из которых просто необходимы для успешного разрешения конфликта. В случае Listing 1, Git предоставил вам только два состояния.
Следующая диаграмма иллюстрирует эти четыре состояния:
Состояния (B) и © относятся к текущим положениям (head) веток master и beta соответственно, эти два состояния как раз таки и отражены в Listing 1. Состояние (D) это результат слияния, то что вы хотите получить/сгенерировать в конечном итоге (в большинстве случаев Git автоматически генерирует состояние (D)). Состояние (А) на самом верху, представляет собой базу (основу) слияния веток master и beta. База слияния (A) это последний общий предок веток master и beta, и пока предположим что это база слияния уникальна. Как мы увидим позже состояние (A) играет ключевую роль в разрешении конфликтов. На диаграмме я также отразил дельты 1 и 2, которые представляют изменения между состояниями (A)-(B), и (A)-© соответственно. Зная состояния (A), (B) и © дельты 1 и 2 могут быть легко получены (вычислены). Обратите внимание, что дельты 1 и 2 могут состоять из более чем одного коммита. Но для наших целей будем считать что все дельты монолитны.
Чтобы понять, как получить состояние (D), вы должны понимать что же операция слияния пытается сделать. Состояние (D) должно представлять собой сочетание изменений, внесённых в ветку master и beta соответственно. Т.е. другими словами сочетание дельт 1 и 2. Идея проста на поверхности и большую часть времени не требует вмешательства со стороны человека, за исключением особых случаев когда дельты затрагивают наслаиваемые (пересекающиеся) части файла. В такой ситуации вам требуется помочь машине сгенерировать результат (D), путём сравнения дельт 1 и 2.
Определение Отличий (Identifying the Differences)
Для того чтобы найти изменения внесённые в каждую ветку, необходимо знать как выглядит база слияния, состояние (A). Самый простой механизм получения информации о базе слияния, это установка опции merge.conflictstyle в значение diff3
$ git config merge.conflictstyle diff3После включения этой опции, попробуйте заново сделать слияние (git reset —hard; git merge master) и проинспектируйте конфликтующий файл ещё раз:
$ cat roses.txt >>>>>> master (Listing 2)Теперь мы видим третий фрагмент посередине, который и является базой слияния или состояние (A). Изменения видны как на ладони: в ветке beta (HEAD) человеческие названия цветов были заменены на HTML коды, а в ветку master добавили капитализацию и пунктуацию. Основываясь на этих знаниях, мы теперь знаем что результат должен включать в себя капитализацию, пунктуацию и HTML коды цветов.
В принципе на этом можно было бы и закончить, потому что результат достигнут. Но есть решение и получше.
Графическое Слияние (GUI Merging)
Хотя и простое текстовое представление конфликта слияния делает свою работу в простых случаях, на практике конфликты могут быть более радикальными и сложными. В таких случаях могут помочь графические инструменты. Мой выбор пал на простой инструмент написанный на Python под названием meld, но может подойти любой другой графический инструмент, способный представить слияние в трёх-колоночном виде.
Для использования графического инструмента (он должен быть установлен), после того как git пожаловался что есть конфликт, введите следующую команду:
$ git mergetoolПоследует вопрос какой программой для слияния вы хотели бы воспользоваться, просто введите meld и нажмите Enter. Вот как окно программы может выглядеть (подразумевается опция merge.conflictstyle не была включена):
Несмотря на то что информация представлена бок о бок, она не отображает нужные фрагменты которые были в Listing 2. Мы не видим здесь фрагмента базы слияния (состояния (A)), что мы видим это файл roses.txt.LOCAL.2760.txt в левой колонке и файл roses.txt.REMOTE.2760.txt в правой колонке и файл посередине это неудачное слияние. Т.е. по сути нам представили состояния (B), © и несостоявшееся состояние (D), но состояние (A) отсутствует.
Правда отсутствует? Давайте проверим, в старом добром терминале:
$ ls -1 roses.txt roses.txt.BACKUP.2760.txt roses.txt.BASE.2760.txt roses.txt.LOCAL.2760.txt roses.txt.REMOTE.2760.txtВидим интересующий нас файл: roses.txt.BASE.2760.txt. Это и есть файл базы слияния. Теперь нам осталось всего лишь найти изменения внесённые в ветки master и beta, по отношению к базе. Мы можем сделать это двумя отдельными вызовами meld:
$ meld roses.txt.LOCAL.2760.txt roses.txt.BASE.2760 & $ meld roses.txt.BASE.2760 roses.txt.REMOTE.2760.txt &(Кто-то может подметить что было бы более разумно, поменять порядок аргументов в первом вызове, для того чтобы файл базы находился в левой колонке в обоих случаях, но именно такой порядок сохраняет подобие трёх-колоночного вида, при котором база остаётся по середине.) Результат выполнения — два окна как показано ниже:
При чтении первого окна справа налево и второго окна слева направо, становится ясно как день, какие изменения произошли в каждой ветке. Так как meld любезно подсветил все изменения, теперь практически не возможно пропустить даже мелко заметные правки (Кто-нибудь заметил добавление предлога «of» при просмотре текстового представления разрешения конфликта Listing 1 или даже Listing 2?)
Вооружившись этими знаниями, мы теперь можем вернуться к трёх-колоночному представлению и сделать изменения. Моя стратегия ручного слияния это взять весь текст из ветки с более весомыми изменениями (в данном случае master/REMOTE т.е. beta), и поверх него производить пошаговые правки, т.е. вносить изменения сделанные в другой ветке (master). Вот что получилось:
А теперь всё вместе (All Together Now)
Надеюсь, вы найдёте этот трёх-окошечный метод разрешения конфликтов, таким же полезным каким нахожу его я. Но согласитесь что запускать новые вызовы meld вручную каждый раз при разрешении конфликтов, не очень то и удобно. Выход, это настроить git таким образом чтобы все три окна открывались автоматически при вызове команды git mergetool. Для этого можно создать выполняемый скрипт, который должен находится в переменной окружения PATH (например $HOME/bin/gitmerge), со следующим содержимым:
#!/bin/sh meld $2 $1 & sleep 0.5 meld $1 $3 & sleep 0.5 meld $2 $4 $3И добавьте следующее в ваш ~/.gitconfig файл:
[merge] tool = mymeld [mergetool "mymeld"] cmd = $HOME/bin/gitmerge $BASE $LOCAL $REMOTE $MERGEDТеперь, когда вы в следующий раз будете запускать команду git mergetool для разрешения конфликта, откроются все три окна:
Окно дифа между BASE и LOCAL Окно дифа между BASE и REMOTE Окно трёх-колоночного видаПосле того как вы привыкните к такому разрешению конфликтов с использованием трёх вышеупомянутых окон, вы скорее всего обнаружите, что процесс стал более методичным и механическим. В большинстве случаев, вам даже не придётся читать и понимать куски кода из каждой ветки, для того чтобы понять какой же вариант применить для слияния. Вам больше не понадобится догадываться, потому что вы будете гораздо более уверенным в корректности вашего комита. Из-за этой уверенности, появится чувство что разрешение конфликтов превратилось в увлекательное занятие.
Бонус от переводчика
Для тех кто пользуется tmux и n?vim, предлагаю следующий скрипт gitmerge:
#!/bin/sh sn=gitmerge tmux new-session -d -s "$sn" -n "diff3" "nvim -d $2 $4 $3" tmux split-window -t "$sn:1" -v "nvim -d $2 $1" tmux split-window -t "$sn:1" -h "nvim -d $1 $3"Примечание: если вы не используете эту опцию в своем ~/.tmux.conf, то вам надо поменять в двух последних строках «$sn:1» на «$sn:0»
Соответственно добавьте следующее в ваш ~/.gitconfig
[mergetool "gitmerge"] cmd = $HOME/bin/gitmerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" [merge] tool = gitmergeВоркфлоу разрешения конфликта будет выглядеть так:
Пока игнорируем вопрос (Was the merge successful [y/n]?) и переключаемся в сессию под названием gitmerge (сочетание TMUXPREFIX + s):
Видим наше трёх-оконное представление на одном экране. Цифрами обозначены сплиты (panes) tmux’a, буквами соответствующие состояния. Делаем правки для разрешения конфликта, т.е. редактируем состояние (D) и сохраняем. После этого возвращаемся обратно в исходную сессию tmux’a и подтверждаем что слияние произошло успешно.
git rebase master
Лично я предпочитаю и считаю более правильным делать сначала rebase master в ветке beta, и только после этого переключаться в master и делать git merge beta. В принципе воркфлоу не сильно отличается, за исключением трёх-оконного вида.
Переключаемся в сессию gitmerge
Обратите внимание, что состояния (B) и © поменялись местами:
Рекомендую всем поиграться с примером репозитария хотя бы один раз, сделать разрешение конфликта по вышеописанной схеме. Лично я больше не гадаю а что же выбрать «Accept theirs» или «Accept yours».
Разрешение конфликта слияния с помощью командной строки
Устраните конфликты слияния с помощью командной строки и текстового редактора.
Platform navigation
Конфликты слияния возникают, если вносятся конкурирующие изменения в ту же строку файла или если один пользователь изменяет файл, а другой этот же файл удаляет. Дополнительные сведения см. в разделе «AUTOTITLE».
Совет. Можно использовать редактор конфликтов в GitHub, чтобы разрешать конкурирующие конфликты слияния изменений строк между ветвями, которые являются частью запроса на вытягивание. Дополнительные сведения см. в разделе «AUTOTITLE».
Конкурирующие конфликты слияния изменений строк
Чтобы разрешить конфликт слияния, вызванный конкурирующими изменениями строк, необходимо выбрать, какие изменения из разных ветвей включить в новую фиксацию.
Например, если несколько человек редактировали файл styleguide.md в одних и тех же строках в разных ветвях одного и того же репозитория Git, будет получена ошибка конфликта слияния при попытке выполнить слияние для этих ветвей. Необходимо разрешить этот конфликт слияния с помощью новой фиксации, прежде чем можно будет выполнить слияние для этих ветвей.
- Откройте Терминал Терминал GIT Bash .
- Перейдите в локальный репозиторий Git, в котором есть конфликт слияния.
cd REPOSITORY-NAME $ 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") If you have questions, please >>>>>> branch-a If you have questions, please open an issue or ask in our IRC channel if it's more urgent. git add . git commit -m "Resolved merge conflict by incorporating both suggestions." Теперь можно выполнять слияние ветвей в командной строке или отправить изменения в удаленный репозиторий в GitHub и выполнить слияние изменений в запросе на вытягивание.
Конфликты слияния файлов удалены
Чтобы разрешить конфликт слияния, вызванный конкурирующими изменениями в файле, когда один пользователь удаляет файл в одной ветви, а другой этот же файл редактирует, необходимо выбрать, следует ли удалить или сохранить удаленный файл в новой фиксации.
Например, если вы редактировали файл, такой как README.md, а другой человек удалил его же в другой ветви того же репозитория Git, вы получите сообщение об ошибке конфликта слияния при попытке выполнить слияние для этих веток. Необходимо разрешить этот конфликт слияния с помощью новой фиксации, прежде чем можно будет выполнить слияние для этих ветвей.
- Откройте Терминал Терминал GIT Bash .
- Перейдите в локальный репозиторий Git, в котором есть конфликт слияния.
cd REPOSITORY-NAME $ 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") git add README.md Чтобы удалить этот файл из репозитория, выполните следующие действия:
$ git rm README.md > README.md: needs merge > rm 'README.md' $ git commit -m "Resolved merge conflict by keeping README.md file." > [branch-d 6f89e49] Merge branch 'branch-c' into branch-d Теперь можно выполнять слияние ветвей в командной строке или отправить изменения в удаленный репозиторий в GitHub и выполнить слияние изменений в запросе на вытягивание.
Дополнительные материалы
- «О конфликтах слияния»
- «Локальное получение для изменения запросов на вытягивание»