Как использовать слияние Git
Это все сливается в одно.
Ключевые выводы
Чтобы объединить ветку разработки с текущей, используйте «git merge dev-branch-name». Если вы получаете предупреждения о конфликте при слиянии, используйте «git merge --abort», чтобы отказаться от него, или отредактируйте затронутые файлы, а затем зафиксируйте их.
Git использует ветки для изоляции потоков разработки и предотвращения загрязнения ветки стабильной версии. Включение работы в ветке в основной поток означает объединение ветвей. Вот как это сделать.
Что такое слияние в Git?
Git был разработан, чтобы сделать ветвление простым и быстрым. В отличие от других систем контроля версий, ветвление в Git — тривиальная задача. Особенно в проектах с участием нескольких разработчиков ветвление является одним из основных организационных инструментов Git.
Новые усилия по разработке ветвей в песочнице, чтобы код можно было изменять или добавлять, не затрагивая код в других ветках, особенно в основной или главной ветке. Обычно он содержит стабильную версию вашей базы кода.
Изолировать эти изменения от вашей стабильной версии кода имеет смысл. Но рано или поздно новый код будет протестирован, проверен и утвержден для включения в основную ветку. На этом этапе вам необходимо объединить свою ветку с основной веткой.
На самом деле ветки могут иметь подветви, поэтому вы можете объединить свою ветку с какой-то другой веткой вместо главной ветки. Просто помните, что слияния всегда берут одну ветку и объединяют ее с целевой веткой, какой бы она ни была. Если вы хотите объединить свою главную ветку с другой веткой, вы тоже можете это сделать.
Как и большинство действий в Git, вы выполняете слияния в локальном репозитории и отправляете их в удаленный репозиторий.
Подготовка к слиянию ветки в Git
У нас есть небольшой проект разработки с локальным и удаленным репозиторием Git. Мы создали ветку под названием «bugfix14» на основе ветки «master» и работали над решением ошибки.
Эта работа завершена, и мы протестировали наш код. Все работает так, как ожидалось. Мы хотим перенести эти изменения в основную ветку, чтобы наше исправление стало частью следующего выпуска программного обеспечения.
Прежде чем выполнить слияние, необходимо провести небольшую подготовку. Нам необходимо убедиться, что целевая ветка (в данном случае «главная» ветка) и ветка, которую мы собираемся объединить с ней, обновлены.
Для этого мы будем использовать
git status
команда.
git status
- В ветке bugfix14: это наша текущая ветка.
- В вашей ветке обновлены «origin/bugfix»: ветка в нашем локальном репозитории имеет ту же историю коммитов, что и ветка в удаленном репозитории. Это означает, что они идентичны.
- нечего фиксировать В промежуточной области нет изменений, которые не были бы зафиксированы.
- Очистка рабочего дерева: в рабочем каталоге нет неустановленных изменений.
Все это указывает на то, что ветка обновлена и мы готовы продолжить. Если бы что-то из этого указывало на наличие изменений, нам нужно было бы их подготовить, зафиксировать и отправить на удаленный компьютер. Если над этими файлами работал кто-то другой, возможно, нам придется извлечь их изменения из удаленного репозитория.
Проверка ветки, в которую мы собираемся выполнить слияние, упрощает процесс слияния. Это также позволяет нам проверить его актуальность. Давайте посмотрим на ветку master.
git checkout master
git status
Мы получаем те же подтверждения, что ветка «master» обновлена.
Выполнение слияния
Прежде чем мы объединимся, наши коммиты выглядят так.
Ветка «bugfix14» была ответвлением ветки «master». После создания ветки «bugfix14» была сделана фиксация ветки «master». В ветку «bugfix14» было сделано несколько коммитов.
Мы убедились, что наши две ветки обновлены, и проверили «главную» ветку. Мы можем ввести команду для объединения ветки «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 не может с этим помочь.