Как использовать слияние Git
Резюме: чтобы объединить ветку разработки с текущей веткой, используйте «git merge dev-branch-name». Если вы получаете предупреждения о конфликте о слиянии, используйте «git merge --abort», чтобы отменить его, или отредактируйте затронутые файлы, а затем зафиксируйте их.
Git использует ветки для изоляции потоков разработки, чтобы предотвратить загрязнение ветки стабильной версии. Приведение работы ветки в основной поток означает слияние веток. Вот как это сделать.
Что такое слияние в Git?
Git был разработан, чтобы сделать ветвление простым и быстрым. В отличие от других систем контроля версий, ветвление в Git — тривиальная задача. Особенно в проектах с несколькими разработчиками ветвление является одним из основных организационных инструментов Git.
Ветки помещают в песочницу новые усилия по разработке, чтобы код можно было изменять или добавлять, не затрагивая код в других ветвях, особенно в основной или главной ветке. Обычно он содержит стабильную версию вашей кодовой базы.
Изолировать эти изменения от вашей стабильной версии кода имеет смысл. Но рано или поздно новый код будет протестирован, проверен и проштампован для включения в основную ветку. В этот момент вам нужно объединить свою ветку с основной веткой.
На самом деле ветки могут иметь ветки, поэтому вы можете объединить свою ветку с какой-то другой веткой, а не с основной веткой. Просто помните, что слияния всегда берут одну ветвь и объединяют ее с целевой ветвью, какой бы она ни была. Если вы хотите объединить свою основную ветку с другой веткой, вы даже можете это сделать.
Как и большинство действий в Git, вы выполняете слияния в своем локальном репозитории и отправляете их в удаленный репозиторий.
Подготовка к слиянию ветки в Git
У нас есть небольшой проект разработки с локальным репозиторием Git и удаленным репозиторием Git. Мы создали ветку под названием «bugfix14» из ветки «master» и работали над решением ошибки.
Эта работа завершена, и мы протестировали наш код. Все работает так, как ожидалось. Мы хотим перенести эти изменения в основную ветку, чтобы наше исправление стало частью следующего выпуска программного обеспечения.
Прежде чем мы выполним слияние, нужно немного подготовиться. Нам нужно убедиться, что целевая ветвь — в данном случае «главная» ветвь — и ветвь, которую мы собираемся объединить с ней, обновлены.
Для этого воспользуемся командой git status.
git status
- В исправлении ошибки 14 ветки: это наша текущая ветка.
- Ваша ветка обновлена с помощью «origin/bugfix»: ветка в нашем локальном репозитории имеет ту же историю коммитов, что и ветка в удаленном репозитории. Это означает, что они идентичны.
- нечего фиксировать В тестовой области нет незафиксированных изменений.
- очистить рабочее дерево: в рабочем каталоге нет неустановленных изменений.
Все это указывает на то, что ветка обновлена, и мы готовы продолжить. Если бы какой-либо из них указывал на наличие изменений, нам нужно было бы подготовить их, зафиксировать и отправить на удаленный сервер. Если кто-то еще работал с этими файлами, нам может потребоваться извлечь их изменения из удаленного репозитория.
Проверка ветки, в которую мы собираемся выполнить слияние, упрощает процесс слияния. Это также позволяет нам проверить его актуальность. Давайте посмотрим на ветку master.
git checkout master
git status
Мы получаем такие же подтверждения, что ветка «master» обновлена.
Выполнение слияния
Перед слиянием наши коммиты выглядят так.
Ветка «bugfix14» была ответвлением ветки «master». Произошла фиксация в ветке «master» после создания ветки «bugfix14». Было несколько коммитов в ветке «bugfix14».
Мы убедились, что наши две ветки обновлены, и проверили ветку «master». Мы можем ввести команду для объединения ветки «bugfix14» с веткой «master».
git merge bugfix14
Происходит слияние. Ветка «bugfix14» все еще существует, но теперь изменения, которые были сделаны в этой ветке, были объединены в ветку «master».
В этом случае команда слияния выполняет трехстороннее слияние. Есть только две ветки, но задействованы три коммита. Они являются главой любой ветки и третьим коммитом, представляющим само действие слияния.
Чтобы обновить наш удаленный репозиторий, мы можем использовать команду git push.
git push
Некоторые люди предпочитают удалять боковые ветки после их объединения. Другие заботятся о том, чтобы сохранить их как запись истинной истории развития проекта.
Если вы хотите удалить ветку, вы можете сделать это с помощью команды git branch с опцией -d (удалить).
git branch -d bugfix14
Чтобы удалить ветку в удаленном репозитории, используйте эту команду:
git push origin --delete bugfix14
У вас будет линейная история коммитов, но это не будет настоящая история.
Выполнение быстрого слияния в Git
Если вы не делали никаких коммитов в ветке «master», ваша история будет выглядеть так. Это также будет выглядеть, если вы перебазировали свою ветку разработки так, чтобы она была прикреплена к концу «главной» ветки.
Поскольку в ветке «master» нет коммитов, для слияния ветки «bugfix15» все, что нужно сделать Git, — это указать указатель «master» на последний коммит ветки «bugfix15».
Мы можем использовать обычную команду git merge:
git merge bugfix15
Это дает нам этот результат.
Что то же самое, что и это:
Что точно так же, как это:
Git будет выполнять ускоренное слияние всякий раз, когда это возможно. Если фиксация в ветке master означает, что ускоренное слияние невозможно, Git будет использовать трехстороннее слияние.
Вы не можете принудительно выполнить ускоренное слияние – в конце концов, это может быть невозможно, – но вы можете объявить, что это будет ускоренное слияние или ничего. Существует параметр, который указывает Git использовать ускоренное слияние, если он может, но не выполнять трехстороннее слияние, если он не может. Параметр --ff-only (только ускоренное слияние).
Это объединяет ветку «bugfix15» с веткой «master», но только если возможно ускоренное слияние.
git merge --ff-only bugfix15
Git пожалуется и выйдет, если это невозможно.
git merge --ff-only bugfix16
В этом случае были зафиксированы в ветке «master», поэтому ускоренное слияние невозможно.
Как разрешить конфликты слияния в Git
Если одни и те же части одного и того же файла были изменены в обеих ветвях, ветки не могут быть объединены. Для разрешения конфликтующих правок требуется вмешательство человека.
Здесь мы внесли изменения в файл с именем «rot.c» в ветке с именем «bugfix17», которую мы хотим объединить с веткой «master». Но «rot.c» был изменен и в ветке «master».
git merge bugfix17
Когда мы пытаемся его объединить, мы получаем предупреждение о наличии конфликтов. Git перечисляет конфликтующие файлы и сообщает нам, что слияние не удалось. Мы могли бы полностью отказаться, используя опцию --abort:
git merge --abort
Но разрешение слияний не так страшно, как кажется. Git проделал некоторую работу, чтобы помочь нам. Если мы отредактируем один из конфликтующих файлов — в нашем случае у нас есть только один — мы обнаружим, что конфликтующие участки кода выделены для нас.
Каждый конфликт ограничен семью символами меньше <<<<<<< и семью символами больше >>>>>>>, с между ними семь знаков равенства «========».
- Код над знаками равенства относится к ветке, которую вы сливаете.
- Код под знаком равенства – это код ветки, которую вы пытаетесь объединить.
Вы можете легко искать один из наборов из семи символов и переходить от конфликта к конфликту через свой файл. Для каждого конфликта вам нужно выбрать, какой набор правок вы собираетесь сохранить. Вы должны отредактировать код, который вы отклоняете, и семисимвольные строки, добавленные Git.
Мы сохраним код из ветки «bugfix17». После редактирования наш файл выглядит так.
Теперь мы можем продолжить слияние. Но обратите внимание: для этого мы используем команду commit, а не команду merge.
Мы фиксируем изменение, подготавливая файл и фиксируя его, как обычно. Мы проверим статус, прежде чем сделать окончательный коммит.
git add rot.c
git status
git commit -m "Merged bugfix17"
Слияние завершено. Теперь мы можем отправить это в наш удаленный репозиторий.
Все сливается в конце концов
Все ветки нужно со временем объединить, чтобы изменения в них не затерялись и не забылись.
Слияние веток — это просто, но улаживать конфликты в больших и загруженных командах может быть сложно. Для разрешения конфликтов может потребоваться участие каждого разработчика только для того, чтобы объяснить, что делает их код и почему они внесли свои изменения. Вы должны понимать это, прежде чем сможете принять обоснованное решение о том, какие правки оставить.
К сожалению, Git не может помочь с этим.