Всем снова привет!
Если вы работаете с Git дольше пары дней и хотя бы иногда подтягиваете чужие изменения, то вы, скорее всего, уже сталкивались с конфликтами.
Обычно это происходит в случайный момент, когда просто хотите обновить ветку и почти на автомате пишите git pull. А в ответ Git жалуется:
CONFLICT (content): Merge conflict in config.py Automatic merge failed; fix conflicts and then commit the result.
После этого открываете файл config.py, на который и указал Git, а там вот эта страшила:
<<<<<<< HEAD DATABASE_URL = "sqlite:////data/app.db" ======= DATABASE_URL = os.getenv("DATABASE_URL") >>>>>>> main
В этой статье мы разберём, как действовать и, главное, мыслить в таких ситуациях. Проблема в том, что конфликтов в git может случиться куча: может сломаться ручной git merge, при git pull, может полететь при git rebase , git cherry-pick и т.д. Из-за этого одного конкретного решения нет, но зато есть общий принцип решения.
Хочу заранее предупредить: я хоть и старался как во всех своих статьях найти более простое объяснение и не прибегать к тонне терминов, но здесь совсем без терминов не получится. Я постараюсь объяснять их по ходу статьи, но базовые вещи вроде commit, branch, pull и push лучше знать заранее.
Что это за маркеры в коде?
Как я уже говорил, при конфликте в git в проблемном файлике появляется фрагмент кода, содержащий с первого взгляда “страшные” маркеры.
На самом деле в них ничего ужасающего нет - это просто разделители двух версий одного фрагмента. Важно, что (разделители) они не являются визуалом: они действительно есть в файле и их действительно нужно будет удалять.
Итак, сначала вспомним, как выглядит весь фрагмент на простом примере.
import os ... # Какой-то код <<<<<<< HEAD DATABASE_URL = "sqlite:////data/app.db" ======= DATABASE_URL = os.getenv("DATABASE_URL") >>>>>>> main # И дальше какой-то код
Если совсем кратко, то:
<<<<<<< HEAD- начало блока кода (изменений) из текущей ветки, в которой вы сейчас находитесь. Это актуально для обычногоmerge, вrebaseс этим будет нюанс - его я раздельно разберу ниже.=======- простой разделитель, который разделяет ваш код от чужого, из другой ветки>>>>>>> main- показывает вторую сторону конфликта. В этом примере изменения пришли из веткиmain.
Фактически Git видит, что ваша текущая версия файла и версия, которую он пытается встроить после pull или merge, по-разному изменили один и тот же участок.
Получается, что все не так страшно, верно? Нужно лишь просто удалить то, что вам не нравится и все разделители (как <<<, >>> так и ===), а потом продолжить работу?
Давайте немного подробнее
При работе с конфликтом важно не столько знать деревянный алгоритм решения, сколько понимать откуда вообще конфликт берется и какие будут последствия от ваших действиях.
Итак, конфликт - это ситуация, когда Git не смог автоматически объединить изменения из разных веток.
Git ругается не потому, что ему скучно. Пока изменения не пересекаются, он спокойно склеивает всё сам. Вот, например, один человек поменял README.md, второй поправил config.py - в такой ситуации никаких вопросов у Git не будет.
Совсем другое дело, если два разработчика поменяли один и тот же участок кода (например значение одной переменной). Не может же Git сам, автоматически решить, чья правка нужна, а чья пойдет в мусорку. Поэтому Git и просит человека самому принять решение: Automatic merge failed; fix conflicts and then commit the result.
Отсюда мы перетекаем к следующей микротеме.
Как работает merge и как возникает конфликт
Если копнуть чуть глубже, Git не сравнивает просто две версии файла. Для объединения изменений он использует так называемое трехстороннее слияние - 3-way merge.
Сначала Git находит исходный коммит, от которого когда-то разошли обе ветки, получившие разные обновления файла (речь не о первом коммите, а о общем коммите-предке, после которого появились изменения). Затем он сравнивает, что именно изменилось относительно этого исходного коммита. То есть фактически он сравнивает не две версии файла, а сразу три:
оригинал файла (из исходного коммита) - возьмем за A;
с изменениями от вас - B;
с изменениями от другого разработчика - C;
Если в B изменения были в одном участке файла, а в C - в другом, то git без проблем объединяет изменения автоматически. Но если же обе ветки изменили один и тот же участок кода относительно A, git, как мы выяснили ранее, уже не может самостоятельно определить, какой вариант должен остаться в итоговом коде.
Git - это все-таки не анализатор кода, он не понимает, какая реализация будет правильнее. Именно поэтому в спорных ситуациях конфликт решаете именно вы.
Пример
<<<<<<< HEAD DATABASE_URL = "sqlite:////data/app.db" ======= DATABASE_URL = os.getenv("DATABASE_URL") >>>>>>> main
Выбор именно такого примера был не случаен, тут спрятана очень неочевидная проблема.
Обычно у людей при виде такого фрагмента в коде возникает желание поскорее все решить: просто выбрать один из двух вариантов. Иногда так и есть, но часто правильное решение - создать третий вариант.
Как мы видим, в примере выше есть две строчки с объявлением переменной DATABASE_URL. Один разработчик решил, что файл БД должен сохраняться именно в /data/app.db и нигде иначе, а другой - что отличным решением будет засунуть значение в переменные окружения. Если просто убрать чье-то решение, то вряд ли все будут довольны.
И если задуматься, то этот конфликт можно решить не деревянным вырезанием одного из вариантов, а созданием третьего, с сохранением обеих идей!
DATABASE_URL = os.getenv("DATABASE_URL", "sqlite:////data/app.db")
Знающий разработчик сразу понял: мы объединили обе строчки и получили не ту прямую логику - хардкод или значение из переменной окружения, а сделали так, чтоб изначально бралось значение DATABASE_URL, но если вдруг эта переменная окружения не была задана, то бралось значение из кода.
На самом деле вариантов решения конфликта обычно несколько. Вы можете:
Оставить свою версию, если изменения из другой ветки уже не нужны;
Оставить чужую версию, если она содержит актуальное решение, а ваше на ее фоне выглядит менее практичным;
Объединить оба варианта в новый код (как по мне - это лучший вариант), как мы сделали с
DATABASE_URL;Полностью переписать спорный участок.
Конфликт также может произойти в автоматически генерируемом файле. Думаю для всех очевидно, что в том же lock-файле вручную склеивать изменения не нужно - легче его просто пересоздать.
И этим я хотел показать важный нюанс: не всегда нужно выбирать один из вариантов кода, важно хотя бы попробовать придумать компромисс.
С чего начинать решение любого конфликта
Теперь, когда уже есть достаточное понимание конфликтов, мы можем переходить к действиям.
Прежде всего, хочу сказать, что git сам довольно хорошо объясняет, в каком состоянии сейчас находится репозиторий, поэтому есть “правило”:
при любом конфликте сначала выполняйте команду git status.
Он покажет:
Какие файлы сейчас находятся в конфликте;
Какая операция остановилась;
Какую команду нужно выполнить после исправления.
Например, если конфликт появился во время обычного merge, вы можете увидеть что-то вроде:
$ 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: config.py
Тут Git сразу говорит, в каком файле конфликт, что файл был изменен с двух сторон (both modified…) и что после исправления нужно сделать git commit.
Если же конфликт появился во время rebase, вывод будет другим:
You are currently rebasing branch 'feature/config' on 'main'. (fix conflicts and then run "git rebase --continue") (use "git rebase --abort" to check out the original branch) Unmerged paths: both modified: config.py
А во время cherry-pick:
You are currently cherry-picking commit a1b2c3d. (fix conflicts and run "git cherry-pick --continue") (use "git cherry-pick --abort" to cancel the cherry-pick operation) Unmerged paths: both modified: config.py
То есть при разных ситуациях, команды после решения конфликтов нужны разные.
Получается, теперь все. Видя подобные сообщения, вы можете без проблем решить конфликт, достаточно лишь увидеть подсказку от самого Git.