Предыдущий ролик Следующий ролик  

Видео урок: Разрешение конфликтов при слиянии

Git: обучение основам

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

Посмотрим, как сделать это. Во-вторых, мы можем разрешить этот конфликт вручную. В большинстве случаев вы и будете так делать, и особенно в тот период, когда вы будете учиться разрешать эти конфликты. А в-третьих, вы можете использовать инструмент для слияния. Есть несколько инструментов, которые помогут вам решить такие конфликты. Я не буду вам их показывать, поскольку их довольно много, и я советую вам не переходить к инструменту для слияния, пока вы вручную не сможете решить эту проблему. То есть, пока вы не решите, какой инструмент подходит для вас и пока не станете абсолютно зависимым от него, я предлагаю вам научиться регулировать такие вещи вручную.

Давайте рассмотрим первый метод, то есть обрывание слияния. Чтобы оборвать слияние, когда мы находимся в таком состоянии, все, что нам нужно сделать, это написать git merge --abort. Вот и все. Обратите внимание, что теперь я не нахожусь в состоянии MERGING, git status, все чисто, а если я напишу git log --oneline для основного бранча, вы видите, что ничего нового не произошло. Все осталось так, как было до слияния. Никакого слияния не было, я просто его прервал. Давайте снова попробуем сделать слияние, git merge text_edits, и вот снова у нас возникает конфликт.

Теперь же мы попробуем разрешить конфликт вручную, проблема возникла в mission.html. Мы снова можем это увидеть, используя git status. И теперь нам нужно разрешить конфликты вручную в mission.html, а затем добавить изменения и закоммитить результат. Вот что мы собираемся сделать. Открываем mission.html. Мы видели эти маркеры, эти стрелочки влево, которые идут к знаку "равно" до стрелочек, ведущих вправо, и теперь мы знаем, где возник конфликт.

Если бы было несколько конфликтов, Git пометил бы их все. Один конфликт может возникнуть вверху документа, один в середине, один внизу, и каждый из них был бы помечен. То есть, всегда будет проблема, и вам нужно просмотреть документ, чтобы увидеть все эти конфликты. Вот тут вверху документа вы можете выбрать поиск и найти все эти проблемные места. Теперь мы видим, что находимся на первом коммите. Мы можем идти строка за строкой и попробовать их отсортировать. Вы можете сами посмотреть. Вы можете сказать - все верно, давайте вернемся, давайте пропишем git log --oneline и поработаем только с этими тремя изменениями.

Все верно, вот этот коммит. О чем он был? Давайте посмотрим, пишем git show и видим этот коммит. Изменение, которое было сделано, заключалось в том, что мы поменяли прямые кавычки на фигурные. Я знаю, что мне нужно взять версию из text_edits, эту версию, здесь есть много версий text_edits. Я беру эту и предполагаю, что она правильная, а теперь я собираюсь убедиться, что во всем документе стоят фигурные кавычки. Теперь берем одинарные кавычки, давайте их поищем, кавычки, которые должны быть изменены, вот тут есть они, и я не уверен, что все они правильные или нет, но я знаю, что вот эти мне надо поменять, это левые двойные кавычки, а это правые двойные кавычки.

Все выглядит довольно хорошо, о, вот здесь есть они, в California's people. Итак, теперь у меня есть все изменения в версии text_edits, и ее я хочу оставить, я хочу убрать это из документа. Также я хочу убрать строки со знаками "равно", а также стрелочки. Теперь документ является обычным HTML документом, и здесь находятся все изменения. Давайте сохраним его, а теперь давайте откроем Firefox и перезагрузим страницу.

Все верно, вы можете ее изучить и убедиться, что все выглядит хорошо, убедиться, что вы полностью довольны результатом, что конфликт при слиянии был разрешен. Если вы полностью довольны, и все изменения были сделаны, сохраните документ и закройте его. Теперь мы переходим в Git и говорим ему, что нужно добавить эти изменения, пишем git add mission.html. Теперь пишем git status, изменения готовы к коммиту. А мы знаем, как сделать коммит, пишем git commit. Обычно после этого мы добавляем сообщение.

Вы можете вставить сообщение, если хотите, но вы не обязаны. Когда вы находитесь в середине процесса слияния, Git покажет стандартное сообщение, которое он использует. То есть, просто git commit, и будет использовано сообщение по умолчанию. Итак, git commit, нажимаем Return, и тогда Git мне скажет, что собирается удалить этот список конфликтов, потому что их уже нет, а затем я просто все сохраняю, закрываю, и Git говорит - все верно, делаю слияние бранча 'text_edits'. если мы напишем git status, ничего нового здесь мы не увидим. Пишем git log --oneline. Давайте взглянем на последние 3 лога, или 4.

Вы видите, что слияние произошло, коммит для слияния на месте, а если мы напишем git branch --merged, Git скажет, что произошло полное слияние text_edits с основным бранчем. Вот так все происходило. Вы открываете файлы, где произошел конфликт, находите проблемное место, исправляете ошибку, и делаете это для всех файлов, где возник конфликт. Если есть 20 файлов, где возникли конфликты, вы исправляете все 20. Затем добавляете все эти файлы в буфер, а когда все готово, вы пишете git commit, и тогда произойдет слияние, все конфликты при слиянии будут разрешены.

Помните, я говорил вам, что есть одна классная возможность, а именно, в git log мы можем использовать --graph, git log --graph, а также мы можем использовать много других опций --oneline, --all, -decorate. И если мы используем их все вместе, посмотрите, что мы получим. Мы видим разные бранчи и то, что в них произошло. Вот бранч shorten_title. Сейчас он выглядит таким образом. Вот здесь показан наш коммит, сделанный при слиянии. Вы видите, что было сделано быстрое слияние для seo_title, и Git не нужен здесь этот коммит при слиянии. А затем мы сделали это слияние, и вы видите, что text_edits до сих пор находится в этой точке во времени, и HEAD указывает на этот коммит, а также он есть в основном бранче.

Это прекрасная возможность, потому что вы получаете графическое представление о бранчах и слиянии. А также я упоминал, что есть третий путь, которым вы можете пойти, а именно, использовать инструмент для слияния, когда вы находитесь в процессе слияния, и конфликт не был разрешен, вы можете написать git mergetool, а затем --tool=, а затем имя инструмента, который вы хотите использовать. Страница Помощь покажет вам разные доступные инструменты, разных кандидатов, которые вы можете использовать. Вы можете посмотреть, как это работает, посмотрите, есть ли тут инструмент, который вам наиболее симпатичен, а также вы можете добавить его в файл git config, если вы хотите использовать именно этот инструмент.

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