Как использовать слияние Git

Опубликовано: 2023-01-03
Две пешеходные дорожки сливаются в одну в травянистом парке.
Мастер Руки/Shutterstock.com
Чтобы объединить ветку разработки с текущей веткой, используйте «git merge dev-branch-name». Если вы получаете предупреждения о конфликте о слиянии, используйте «git merge --abort», чтобы отменить его, или отредактируйте затронутые файлы, а затем зафиксируйте их.

Git использует ветки для изоляции потоков разработки, чтобы предотвратить загрязнение ветки стабильной версии. Приведение работы ветки в основной поток означает слияние веток. Вот как вы это делаете.

Оглавление

Что такое слияние в Git?
Подготовка к слиянию ветки в Git
Выполнение слияния
Выполнение быстрого слияния в Git
Как разрешить конфликты слияния в Git
Все сливается в конце концов

Что такое слияние в Git?

Git был разработан, чтобы сделать ветвление простым и быстрым. В отличие от других систем контроля версий, создание ветвей в Git — тривиальная задача. Особенно в проектах с несколькими разработчиками ветвление является одним из основных организационных инструментов Git.

Ветки помещают в песочницу новые усилия по разработке, чтобы код можно было изменять или добавлять, не затрагивая код в других ветвях, особенно в основной или главной ветке. Обычно он содержит стабильную версию вашей кодовой базы.

Изолировать эти изменения от вашей стабильной версии кода имеет смысл. Но рано или поздно новый код будет протестирован, проверен и проштампован для включения в основную ветку. В этот момент вам нужно объединить свою ветку с основной веткой.

Как работают ветки Git?
СВЯЗАННЫЕ Как работают ветки Git?

На самом деле ветки могут иметь ветки, поэтому вы можете объединить свою ветку с какой-то другой веткой, а не с основной веткой. Просто помните, что слияния всегда берут одну ветвь и объединяют ее с целевой ветвью, какой бы ни была эта ветвь. Если вы хотите объединить свою ветку master с другой веткой, вы даже можете это сделать.

Как и большинство действий в Git, вы выполняете слияния в своем локальном репозитории и отправляете их в удаленный репозиторий.

Подготовка к слиянию ветки в Git

У нас есть небольшой проект разработки с локальным репозиторием Git и удаленным репозиторием Git. Мы создали ветку под названием «bugfix14» из ветки «master» и работали над решением ошибки.

Эта работа завершена, и мы протестировали наш код. Все работает так, как ожидалось. Мы хотим перенести эти изменения в основную ветку, чтобы наше исправление стало частью следующего выпуска программного обеспечения.

Прежде чем мы выполним слияние, нужно сделать небольшую подготовку. Нам нужно убедиться, что целевая ветвь — в данном случае «главная» ветвь — и ветвь, которую мы собираемся объединить с ней, обновлены.

Для этого воспользуемся командой git status .

 статус git 

Использование git status для просмотра состояния ветки

  • В ветке bugfix14 : это наша текущая ветка.
  • Ваша ветка обновлена ​​с помощью «origin/bugfix» : ветка в нашем локальном репозитории имеет ту же историю коммитов, что и ветка в удаленном репозитории. Это означает, что они идентичны.
  • ничего для фиксации В промежуточной области нет изменений, которые не были зафиксированы.
  • рабочее дерево чистое : в рабочем каталоге нет неустановленных изменений.

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

Проверка ветки, в которую мы собираемся выполнить слияние, упрощает процесс слияния. Это также позволяет нам проверить его актуальность. Давайте посмотрим на ветку master.

 мастер проверки git
 статус git 

Проверка основной ветки и использование git status для просмотра ее состояния

Мы получаем такие же подтверждения, что ветка «master» обновлена.

СВЯЗАННЫЕ С: Как выбрать модель рабочего процесса и ветвления Git, подходящую для вашей команды

Выполнение слияния

Перед слиянием наши коммиты выглядят так.

История коммитов до слияния ветки

Ветка «bugfix14» была ответвлением ветки «master». Произошла фиксация в ветке «master» после создания ветки «bugfix14». Было несколько коммитов в ветке «bugfix14».

Мы убедились, что наши две ветки обновлены, и проверили ветку «master». Мы можем ввести команду для объединения ветки «bugfix14» с веткой «master».

 Исправление ошибки git слияния 14 

слияние ветки с помощью команды git merge

Происходит слияние. Ветка «bugfix14» все еще существует, но теперь изменения, которые были сделаны в этой ветке, были объединены в ветку «master».

История коммитов после слияния ветки

В этом случае команда слияния выполняет трехстороннее слияние . Есть только две ветки, но задействованы три коммита. Они являются главой любой ветки и третьей фиксацией, которая представляет само действие слияния.

Чтобы обновить наш удаленный репозиторий, мы можем использовать команду git push .

 git push 

Отправка изменений в удаленный репозиторий

Некоторые люди предпочитают удалять боковые ветки после их слияния. Другие заботятся о том, чтобы сохранить их как запись истинной истории развития проекта.

Если вы хотите удалить ветку, вы можете сделать это с помощью команды git branch с параметром -d (удалить).

 git ветка -d bugfix14 

Удаление ветки в локальном репозитории

Чтобы удалить ветку в удаленном репозитории, используйте эту команду:

 git push origin --delete bugfix14 

Удаление ветки в удаленном репозитории

У вас будет линейная история коммитов, но это не будет настоящая история.

СВЯЗАННЫЕ С: Как удалить ветки Git в локальных и удаленных репозиториях

Выполнение быстрого слияния в Git

Если вы не делали никаких коммитов в ветке «master», ваша история будет выглядеть так. Это также будет выглядеть, если вы перебазировали свою ветку разработки так, чтобы она была прикреплена к концу «главной» ветки.

История коммитов до быстрого слияния

Поскольку в ветке «master» нет коммитов, для слияния ветки «bugfix15» все, что нужно сделать Git, — это указать указатель «master» на последний коммит ветки «bugfix15».

Мы можем использовать обычную команду git merge :

 Исправление ошибки git слияния 15

Это дает нам этот результат.

Один из способов просмотреть результат быстрого слияния

Что то же самое, что и это:

Еще один способ просмотреть результат быстрого слияния.

Что точно так же, как это:

Еще один способ просмотреть результат быстрого слияния.

Git будет выполнять ускоренное слияние всякий раз, когда это возможно . Если коммиты в ветке «master» означают, что ускоренное слияние невозможно, Git будет использовать трехстороннее слияние .

Вы не можете форсировать ускоренное слияние — в конце концов, это может быть невозможно, — но вы можете объявить, что это будет ускоренное слияние или ничего. Существует параметр, который указывает Git использовать ускоренное слияние, если он может, но не выполнять трехстороннее слияние, если он не может. Опция --ff-only (только ускоренное слияние).

Это объединяет ветку «bugfix15» с веткой «master», но только если возможно ускоренное слияние.

 git слияние --ff-только исправление 15 

Использование параметра --ff-only для предотвращения использования трехстороннего слияния, если ускоренное слияние невозможно.

Git пожалуется и выйдет, если это невозможно.

 git слияние --ff-только исправление 16 

Git не выполняет слияние, поскольку ускоренное слияние невозможно и используется параметр --ff-only.

В этом случае были зафиксированы в ветке «master», поэтому ускоренное слияние невозможно.

Как разрешить конфликты слияния в Git

Если одни и те же части одного и того же файла были изменены в обеих ветвях, ветки не могут быть объединены. Для разрешения конфликтующих правок требуется вмешательство человека.

Здесь мы внесли изменения в файл с именем «rot.c» в ветке с именем «bugfix17», которую мы хотим объединить с веткой «master». Но «rot.c» был изменен и в ветке «master».

 Исправление ошибки git слияния 17 

Получите сообщения о конфликтах и ​​​​остановку слияния

Когда мы пытаемся его объединить, мы получаем предупреждение о наличии конфликтов. Git перечисляет конфликтующие файлы и сообщает нам, что слияние не удалось. Мы могли бы полностью отказаться, используя опцию --abort :

 git слияние --abort

Но разрешение слияний не так страшно, как кажется. Git проделал некоторую работу, чтобы помочь нам. Если мы отредактируем один из конфликтующих файлов — в нашем случае у нас есть только один — мы обнаружим, что конфликтующие участки кода выделены для нас.

Как git определяет конфликты внутри файла

Каждый конфликт ограничен семью символами «меньше» « <<<<<<< » и семью символами «больше чем» « >>>>>>> », с семью знаками равенства « ======= » между ними. .

  • Код над знаками равенства взят из ветки, в которую вы сливаетесь .
  • Код под знаком равенства — это код ветки, которую вы пытаетесь объединить .

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

Мы сохраним код из ветки «bugfix17». После редактирования наш файл выглядит так.

Отредактированный текст, разрешающий конфликт слияния

Теперь мы можем продолжить слияние. Но обратите внимание: для этого мы используем команду commit , а не команду merge .

Мы фиксируем изменение, подготавливая файл и фиксируя его, как обычно. Мы проверим статус, прежде чем сделать окончательный коммит.

 git добавить rot.c
 статус git
 git commit -m "Объединено bugfix17" 

Использование команды фиксации для завершения слияния после разрешения конфликтов

Слияние завершено. Теперь мы можем отправить это в наш удаленный репозиторий.

СВЯЗАННЫЕ С: Как исправить, отредактировать или отменить коммиты Git (изменение истории Git)

Все сливается в конце концов

Все ветки нужно со временем объединить, чтобы изменения в них не затерялись и не забылись.

Слияние веток — это просто, но улаживать конфликты в больших и загруженных командах может быть сложно. Разрешение конфликтов может потребовать участия каждого разработчика только для того, чтобы объяснить, что делает их код и почему они внесли свои изменения. Вы должны понимать это, прежде чем сможете принять обоснованное решение о том, какие правки оставить.

К сожалению, Git не может помочь с этим.

СВЯЗАННЫЕ: Стоит ли использовать Git-клиент с графическим интерфейсом?