На ранних этапах моей карьеры конфликт слияния был для меня настоящим кошмаром. Думаю, я не одна такая.
Я закончила курсы программирования в 2018 году. В те времена, столкнувшись с проблемой с git, с которой не могла справиться, я просто создавала новый репозиторий и начинала все сначала.
В 2019 году я начала работать в команде с другими разработчиками и уже не могла избегать проблем, просто создавая новые репозитории. Мне пришлось посмотреть в лицо своему страху и научиться разрешать конфликты слияния.
Это было непросто. К счастью, сегодня я чувствую себя более уверенно. Конфликты по-прежнему раздражают, но теперь у меня в арсенале есть пара приемов для исправления ситуации.
Предварительные условия для разрешения конфликта слияния
Дышите глубже
Все в порядке. Конфликты случаются. Вы не первый человек, столкнувшийся с конфликтом слияния. С ними сталкиваются все разработчики, а частота инцидентов зависит от опыта. Конфликты — распространенное явление в контроле версий.
Разберитесь, почему возник конфликт слияния
Системы контроля версий вроде Git автомагически управляют контрибуциями кода. Они идентифицируют изменение, момент его появления, автора и то, в какой строке это изменение появилось. Благодаря этому разработчики могут легко отследить историю своей кодовой базы.
Но иногда Git бывает сбит с толку. Например, в следующих ситуациях:
- Двое или больше людей изменили одну и ту же строку в файле и пытаются смержить изменения в одну и ту же ветку
- Один разработчик удалил файл, а другой его отредактировал, и оба пытаются смержить свои изменения в одну ветку
- Один разработчик удалил строку, а другой ее отредактировал, и оба пытаются смержить свои изменения в одну ветку
- Разработчик взял изменения из одного коммита в ветке и попытался применить их в виде нового коммита (
cherry-pick) - Разработчик сделал rebase ветки: переместил последовательность коммитов в базовый коммит.
Git не уверен, какие изменения нужно применить, поэтому обращается за помощью к разработчику — посылает уведомление о конфликте слияния. Ваша задача — помочь Git определить, какие из изменений наиболее точны.
Разрешение конфликтов слияния
В редакторе кода или IDE
Загляните в логи
Если вы запустили git merge и возник конфликт слияния, ваш терминал или командная строка ответит вам сообщением:
CONFLICT (content): Merge conflict in [filename]
Это сообщение говорит нам, в каком конкретно файле возник конфликт.
Найдите конфликт
Откройте файл, на который указал Git, и прокрутите его, пока не найдете конфликт. Ваша IDE может подсказать вам нужное место при помощи подсветки. В примере ниже показано, как это выглядит в VS Code. Редактор подсвечивает текущее изменение и входящее.
- Текущее изменение (англ. current change) также иногда называют исходящим. Оно представляет изменения в коде, которые вы сделали в вашей локальной ветке.
- Входящее изменение (англ. incoming change) представляет изменения в коде, которые вы вытягиваете (pull) из базовой ветки, или изменения, внесенные другими разработчиками.
Решите, какие изменения нужно применить
То, хотите ли вы принять текущие изменения, входящие изменения или все изменения, зависит от ваших целей. При принятии решения вы ориентируетесь на свое понимание этих изменений.
Если вы не знаете, как поступить, лучше всего посоветоваться с командой или тем разработчиком, который написал входящие изменения.
Вы можете принять изменения, не делая коммит, и локально протестировать программу на работоспособность.
Удалите все длинные последовательности символов ==== , <<<< или >>>>
Эти символы используются для того, чтобы помочь вам определить, где возник конфликт слияния. При принятии выбранных изменений они обычно исчезают, но порой случаются сбои. Проследите за тем, чтобы случайно не включить их в коммит: это может привести к багам в программе.
Что, если я ошибся?
Если вы допустили ошибку или не уверены в том, какие изменения нужно принять, вы можете остановить процесс слияния, запустив следующую команду:
git merge --abort
После этого не надо сидеть и смотреть в пустоту. Обратитесь к коллегам (желательно, к тому, чей код конфликтует с вашим, или к тому, кому больше доверяете). Объясните ситуацию: «Слушай, у меня возник конфликт слияния. Я не знаю, какие изменения принять. У тебя есть пара минут, чтобы мне помочь?»
Если вы уверены, что конфликт разрешен, сделайте коммит изменений
После принятия нужных изменений вы можете сделать коммит. Проделайте следующие шаги:
- Сохраните файлы, в которые были внесены изменения
- Запустите
git statusи проверьте, что изменения коснулись правильных файлов - Добавьте выбранные файлы в стейджинг:
git add [имя файла] - Сделайте коммит изменений:
git commit -m «[ваше сообщение коммита]» - Запустите
git push
На GitHub
Определите, в каких файлах возник конфликт
При открытии пул-реквеста на GitHub в случае конфликта вы получите уведомление об этом. В нем также будет информация о соответствующих файлах.
Найдите конфликт
Чтобы найти конфликты, нажмите «Resolve conflicts». Это приведет вас к нужным файлам.
Определите, какие изменения нужно принять
Веб-интерфейс GitHub подсвечивает конфликтующие изменения желтым цветом и выделяет символами <<<<<, ====, >>>>.
GitHub также указывает на ветки, из которых происходят эти изменения. Это должно помочь вам решить, какие изменения следует принять. Будут это изменения из вашей ветки, из базовой или обеих — зависит от вас. При выборе опирайтесь на свои знания и мнение коллег.
Удалите строки, которые не нужны. Также удалите все лишние последовательности символов ====, <<<< или >>>>.
Когда будете уверены, что конфликт разрешен, сделайте коммит изменений
Удалив конфликтующие изменения и все символы, которые использовались для их выделения, нажмите «Mark as Resolved» и затем «Commit merge».
Больше о конфликтах слияния и их разрешении можно почитать в официальной документации GitHub.
Перевод статьи «How Do I Resolve Merge Conflicts?».
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
