что такое слияние двух веток
Введение в Git Merge и Git Rebase: зачем и когда их использовать
Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git Merge
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной. 
Плюсы:
Слейте ветку master в ветку feature, используя команды checkout и merge.
Это создаст новый «Merge commit» в ветке feature, который содержит историю обеих веток.
Git Rebase
Rebase — еще один способ перенести изменения из одной ветки в другую. Rebase сжимает все изменения в один «патч». Затем он интегрирует патч в целевую ветку.
В отличие от слияния, перемещение перезаписывает историю, потому что она передает завершенную работу из одной ветки в другую. В процессе устраняется нежелательная история.
Переместите ветку feature на главной ветке, используя следующие команды.
Это перемещает всю ветку функции в главную ветку. История проекта изменяется, создаются новые коммиты для каждого коммита в основной ветке.
Интерактивное перемещение
Это позволяет изменять коммиты при их перемещении в новую ветку. Это лучше, чем автоматическое перемещение, поскольку обеспечивает полный контроль над историей коммитов. Как правило, используется для очистки истории до слияния ветки feature в master.
Это откроет редактор, перечислив все коммиты, которые будут перемещены.
Это точно определяет, как будет выглядеть ветка после выполнения перемещения. Упорядочивая объекты, вы можете сделать историю такой, как захотите. Вы можете использовать команды fixup, squash, edit, и так далее.
Какой из них использовать?
Так что же лучше? Что рекомендуют эксперты?
Трудно принять единственно правильное решение о том, что лучше использовать, поскольку все команды разные. Всё зависит от потребностей и традиций внутри команды.
Принимайте решения на основании компетенции команды в Git. Для вас важна простота или перезаписывание истории, а может быть что-то другое?
По мере роста команды становится сложно управлять или отслеживать изменения в разработке, применяя слияние. Чтобы иметь чистую и понятную историю коммитов, разумно использовать Rebase.
Git для начинающих. Урок 9.
Слияния или мерджи веток
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Подробнее о разных соглашениях мы поговорим во второй части курса.
Что такое мердж или слияние веток
Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.
Мердж ветки в мастер
Выполняется после завершения работы над своей веткой при помощи команды git merge. Чтобы вмерджить ветку в мастер, нужно сначала перейти в мастер, а затем выполнить git merge branch_name.
При этом возможны разные ситуации
Поговорим о них подробнее
Пока мы работали над веткой, в мастере не появилось новых коммитов
То есть мы создали ветку, поработали над ней, собрались заливать ее в мастер, а за это время новых коммитов там не появилось. Тогда слияние проходит так
Git понимает, что это новый код, который можно просто положить поверх старого. Это простая ситуация и git не задает никаких вопросов.
Не забудьте сразу запушить изменения, чтобы их увидели коллеги, и удалить локальную ветку header, если она больше не нужна.
Теперь другая ситуация.
Пока мы работали над веткой, в мастере появились коммиты от коллег
Сначала переключаемся на мастер
Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем
Мерджим свою ветку в мастер
И не забываем запушить изменения
Что если сначала не подтягивать мастер, а смерджить свою ветку
Принципиально ничего не изменится, но лучше сначала сделать актуальной ветку мастер, а уже потом заливать свои изменения. А еще лучше держать актуальной свою ветку относительно мастера. Это значит, что стоит почаще подтягивать мастер в свою ветку. Таким образом мы в своей ветке будем работать с актуальным кодом и у нас меньше риска что-нибудь поломать. А если поломаем, то лучше чинить это в своей ветке, а не в мастере.
Как вмерджить мастер в свою ветку
Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master
Затем проверяем, что ничего не поломалось и продолжаем работать.
Мердж коммиты
Чем чаще мерджить между собой ветки, тем больше появляется так называемых мердж-коммитов. Такой коммит появляется каждый раз, когда мы подтягиваем мастер в свою ветку или сливаем свою ветку в мастер. Эти коммиты не хранят изменений, они хранят только факт мерджа одной ветки в другую.
Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754
Посмотрим его содержимое
То есть информация только о том, что в мастер была залита ветка news. Сами изменения в файлах, которые мы делали в ветке news, лежат в других коммитах.
Споры о том, есть польза от таких коммитов, ведутся годами и не закончатся, видимо, никогда.
Мерджи всегда проходят так гладко?
В этом уроке мы намеренно упрощали ситуацию и рассматривали случаи, когда наши коллеги делают изменения в других участках кода. То есть мы с ними даже не пересекались. В реальной жизни так происходит не всегда. Иногда мы правим одни и те же участки кода и тогда при их слиянии git не может понять, чей вариант правильный. Это называется возникновения конфликта.
Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.
Git. Урок 5.
Слияние изменений и продвинутая
работа с ветками.
Команды: merge, cherry-pick, rebase.
1. Что такое слияние и зачем оно нужно.
2. Слияние в Git. Команда git merge.
2.1 Явное слияние
2.2 Неявное слияние (fast-forward)
2.3 В чем разница между fast-forward и явным слиянием?
3. Разрешение конфликтов слияния.
3.1. Ручное разрешение конфликта
3.2. Выбор одного из двух файлов
3.3. Тонкости разрешения merge-конфликтов.
3.4. Инструменты для разрешения merge-конфликтов.
4. Еще один способ объединения изменений из разных веток. Команда git rebase.
5. Интерактивный git rebase. Редактирование коммитов любой давности.
6. Берем вишенку с торта. Команда git cherry-pick.
То есть общий ход нашей работы выглядит следующим образом:
1. Решили добавить новую функцию – создали отдельную ветку. Дальше работаем в новой ветке.
2. Написали функцию, протестировали ее работу, внесли все необходимые исправления, еще раз протестировали и убедились, что функция работает исправно и не привнесла ошибок в остальной код.
3. Теперь нужно как-то перенести изменения с тестовой ветки на основную – в продакшн. Тут нам на помощь и приходит слияние: мы просто сливаем (т.е. переносим) изменения с нашей тестовой ветки в основную.
Итак, дадим определения:
Команда git merge
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать слияние и вернуть все к моменту начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить слияние после разрешения всех конфликтов.
2. 1. Явное слияние
Допустим, у нас есть граф вида:
Флаг —no-ff в данной ситуации необходим, поскольку мы хотим выполнить именно явное слияние. Подробнее о смысле этого флага мы поговорим чуть позже.
2.2. Неявное слияние
Давайте рассмотрим пример. Допустим, у нас есть все тот же граф репозитория:
Очень часто во время слияния веток оказывается, что ваши изменения удаляют или переписывают информацию в уже существующих файлах. Такая ситуация называется файловым конфликтом. Git останавливает выполнение слияния, пока вы не разрешите конфликт.
По сути, Git сталкивается с проблемой: у него есть два файла с одним и тем же именем, и он не знает, какой из них взять. Поэтому обращается к нам за помощью.
Давайте сразу начнем с примера и по ходу будем учиться разрешению конфликтов. Так будет нагляднее. Итак, допустим есть следующий репозиторий:
3.1. Ручное разрешение конфликта
3.2. Выбор одного из двух файлов
Дальше все стандартно: откроется редактор сообщения коммита. В сообщении следует указать, какие ветки вы сливали, и вкратце перечислить внесенные изменения.
3.3. Тонкости разрешения merge-конфликтов.
Теперь мы имеем представление, как разрешать конфликты слияния, и пришло время углубиться в эту тему. Поговорим о тонкостях, которые помогут вам понять, как правильно разрешить конфликт. Подчеркиваем: «правильно», поскольку разрешить конфликт не составляет труда, но если сделать это неверно, можно потерять код, написанный другими разработчиками.
Видно, что файлы различаются, но из этого представления совсем непонятно, что именно должно войти в итоговый файл. Если бы это был ваш личный проект, вы бы прекрасно знали, какой из файлов выбрать, но это чужой репозиторий и цена ошибки велика. Конечно, можно потратить много времени, перебирая коммиты из обеих веток, разбираясь, как менялись файлы, чтобы понять, что должно быть в итоговом файле. Но можно поступить проще. Прежде всего, давайте изучим немного теории.
Итак, при слиянии двух веток используются четыре состояния, и три из них необходимы, чтобы разрешить конфликт правильно. Давайте разбираться, что это за состояния.
Эти состояния можно изобразить на диаграмме следующим образом.
Чтобы понять, что изображено на диаграмме, полезно будет вспомнить, что такое дельта.
Дельта – это разность каких-то двух состояний. То есть по сути это информация о том, какие изменения вы внесли в файлы с момента определенного коммита. Как мы помним из второго урока данного курса, коммиты хранят именно дельты, а не полностью файлы. Благодаря этому репозиторий Git занимает очень мало места.
На диаграмме выше Дельта-1 – это разность текущего состояния ветки main и базы слияния. Аналогично Дельта-2 – это разность текущего состояния ветки develop и базы слияния.
Результат слияния нам как раз и нужно получить. Git пытается получить его автоматически, совмещая Дельту-1 и Дельту-2, но если эти дельты задевают одни и те же части одного и того же файла, возникает конфликт. При возникновении конфликта Git просит нас сравнить Дельту-1 и Дельту-2, чтобы составить из них третье состояние – результат слияния.
3.4. Инструменты для разрешения merge-конфликтов.
Использование графических утилит особенно удобно при сравнении больших файлов: почти во всех есть подсветка внесенных изменений, что поможет вам не запутаться в файле. Тем не менее при сравнении маленьких файлов часто можно обойтись одной консолью. Кстати, большинство IDE имеет встроенную утилиту для разрешения конфликтов, что сделает вашу работу с кодом еще более удобной.
Если говорить кратко, git rebase переносит коммиты текущей ветки на вершину переданной. Но перед тем, как перейти непосредственно к команде, давайте разберем принцип ее действия на примере. Пусть у нас есть репозиторий со следующим графом.
Команда git rebase
-i
—interative
Эти ключи позволяют нам делать rebase в интерактивном режиме. Мы будем активно пользоваться ими при редактировании старых коммитов.
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать ребейз и вернуть все к моменту до начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить ребейз после разрешения всех конфликтов.
—skip
Ключ, использующийся только при разрешении конфликтов. Позволяет пропустить текущий коммит.
После выполнения всех вышеуказанных операций, граф репозитория будет выглядеть так.
В предыдущем уроке мы с вами разобрали, помимо прочего, как можно объединить несколько последовательных коммитов в один и как редактировать содержимое и сообщение последнего коммита ветки. Но что если мы хотим отредактировать более ранний коммит? Git предоставляет нам и такую возможность. Правда тут мы воспользуемся небольшой хитростью.
На самом деле git rebase можно выполнять для одной и той же ветки. В обычном режиме это нам ничего не даст, но вот в интерактивном режиме мы сможем поменять сообщения, содержимое и вообще манипулировать коммитами, как нам только вздумается, вплоть до удаления. Давайте на примере разберем, как происходит изменение коммитов. Итак, допустим у нас есть репозиторий, граф которого выглядит так:
Команда git cherry-pick
-e
—edit
С этим ключом вы сможете отредактировать сообщение коммита.
-n
—no-commit
С этим ключом команда не создаст коммит на вашей ветке, а только скопирует все изменения в вашу рабочую копию. То есть с этим ключом данная команда идентичная git checkout *
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать операцию и вернуть все к моменту до начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить операцию после разрешения всех конфликтов.
Берет переданный коммит и создает в текущей ветке его точную копию.
Также в команду можно передать первый и последний коммит последовательности, тогда та же операция будет выполнена для всех коммитов последовательности.
1. Случай первый. Работа в команде.
Этот случай был описан во введении к данной части. Часто в команде несколько разработчиков работают над одним и тем же участком кода, но каждый – в своей ветке. Соответственно могут возникать ситуации, когда одному из разработчиков для реализации своей части задачи потребуется часть кода, написанная другим разработчиком. Merge в данном случае делать нерационально, поскольку ни одна из веток не пришла к своему логическому завершению, а вот cherry-pick – то, что надо.
2. Случай второй. Быстрые исправления багов.
Если в коде был обнаружен баг, очень важно как можно быстрее донести исправления до конечного пользователя. В таком случае, разработчик, обнаруживший ошибку, срочно создает коммит, в котором исправляет ее. Этот коммит может быть перенесен в основную ветку с помощью cherry-pick, чтобы не задерживать исправление бага слияниями в различные пре-релизные ветки.
Тонкости благополучного git-merge
Вступительное слово
Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.
Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.
Здесь я хочу рассмотреть только случай благополучного слияния, под которым я понимаю слияние без конфликтов. Обработка и разрешение конфликтов — отдельная интересная тема, достойная отдельной статьи. Я очень рекомендую так же ознакомиться со статьей Внутреннее устройство Git: хранение данных и merge, содержащей много важной информации, на которую я опираюсь.
Анатомия команды
Если верить мануалу, команда имеет следующий синтаксис:
По большому счету, в Git есть два вида слияния: перемотка (fast-forward merge) и «истинное» слияние (true merge). Рассмотрим несколько примеров обоих случаев.
«Истинное» слияние (true merge)
Мы отклоняемся от ветки master, чтобы внести несколько багов улучшений. История коммитов у нас получилась следующая:
Выполним на ветке master git merge feature :
Посмотрим историю коммитов в тестовом репозитории, который я создал специально для этого случая:
А теперь посмотрим информацию о коммите (M):
Мы видим двух родителей, объект-дерево, соответствующее данному состоянию файлов репозитория, а так же информацию о том, кто виновен в коммите.
Посмотрим, куда ссылается указатель master:
Действительно, он теперь передвинут на коммит (M).
Squash и no-commit
В случае применения такого слияния коммиты ветки feature не будут включены в нашу историю, но коммит Sq будет содержать все их изменения:
Позже, в случае выполнения «классического» git merge feature можно исправить это. Тогда история примет следующий вид:
Перемотка (fast-forward merge)
Рассмотрим другой случай истории коммитов:
Все как и в прошлый раз, но теперь в ветке master нет коммитов после ответвления. В этом случае происходит слияние fast-forward (перемотка). В этом случае отсутствует коммит слияния, указатель (ветка) master просто устанавливается на коммит Y, туда же указывает и ветка feature:
Стратегии слияния
Стратегия resolve
Здесь C — общий коммит двух веток, дерево файлов, соответствующее этому коммиту, принимается за общего предка. Анализируются изменения, произведенные в ветках master и feature со времен этого коммита, после чего для коммита (M) создается новая версия дерева файлов в соответствии с пунктами 4 и 5 нашего условного алгоритма.
Стратегия recursive
Для иллюстрации этой стратегии позаимствуем пример из статьи Merge recursive strategy из блога «The plasticscm blog»:
Итак, у нас есть две ветки: main и task001. И так вышло, что наши разработчики знают толк в извращениях: они слили коммит 15 из ветки main с коммитом 12 из ветки task001, а так же коммит 16 с коммитом 11. Когда нам понадобилось слить ветки, оказалось, что поиск реального предка — дело неблагодарное, но стратегия recursive с ее конструированием «виртуального» предка нам поможет. В результате мы получим следующую картину:
]
Выполнение рекурсивного слияния с этой опцией будет более продвинутым вариантом стратегии subtree, где алгоритм основывается на предположении, как деревья должны совместиться при слиянии. Вместо этого в этом случае указывается конкретный вариант.
Стратегия octopus
Эта стратегия используется для слияние более чем двух веток. Получившийся в итоге коммит будет иметь, соответственно, больше двух родителей.
Данная стратегия предполагает большую осторожность относительно потенциальных конфликтов. В связи с этим порой можно получить отказ в слиянии при применении стратегии octopus.
Стратегия ours
Не следует путать стратегию ours и опцию ours стратегии recursive.
Стратегия ours — более радикальное средство.
Стратегия subtree
Для иллюстрации данной стратегии возьмем пример из главы Слияние поддеревьев книги «Pro Git».
Добавим в наш проект новые удаленный репозиторий, rack:
Ясно, что ветки master и rack_branch имеют абсолютно разные рабочие каталоги. Добавим файлы из rack_branch в master с использованием squash, чтобы избежать засорения истории ненужными нам фактами:
Теперь файлы проекта rack у нас в рабочем каталоге.
Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
Вы работаете над сайтом.
Вы создаете ветку для новой статьи, которую вы пишете.
Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
Переключиться на основную ветку.
Создать ветку для добавления исправления.
После тестирования слить ветку содержащую исправление с основной веткой.
Переключиться назад в ту ветку, где вы пишете статью и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Это то же самое что и:
Вы работаете над своим сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на нее ранее ( HEAD указывает на нее).
Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку для исправления, в которой будем работать, пока не закончим исправление.
Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над проблемой #53:
Основы слияния
Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
Основные конфликты слияния
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.