Git Merge vs Git Rebase

Git Merge vs Git Rebase

Наши соц. сети: instagram, fb, tg

Как merge, так и rebase предназначены для интеграции изменений из нескольких веток в одну. И хотя их конечная цель одна, способы ее достижения все же разные.

Merge

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

merge

Преимущества

Простота

Сохраняет всю историю и хронологический порядок

Сохраняет контекст

Недостатки

История коммитов обрастает множеством коммитов слияния

Отладка с использованием git bisect может стать сложнее

Как это сделать

Объединить основную ветку с функциональной веткой вы можете с помощью команд checkout и merge.


$ git checkout feature

$ git merge master


Rebase

Перебазирование - это еще один способ интегрировать изменения одной ветки в другую. Однако, в отличие от merge, rebase сжимает все изменения и интегрирует их в целевую ветку. При этом удаляется история.

rebase

Преимущества

Очищает историю

Управлять одиночным коммитом проще (например, отменить его)

Избегает «шума» коммитов слияния в загруженных репозиториях с загруженными ветвями

Очищает промежуточные коммиты, что может быть полезно для команд DevOps

Недостатки

Сжатие веток функциональности до нескольких коммитов может скрыть контекст

Перебазирование общедоступных репозиториев может быть опасным при работе в команде

Больше работы: использование rebase для постоянного обновления ветки функций

При желании восстановить удаленные ветки потребуется git push --force. При этом git push может быть не установлен по умолчанию, что приведет к обновлению всех ветвей с одинаковыми именами как локальных, так и удаленных.

Как это сделать

Переместить функциональную ветку в основную можно, используя следующие команды:


$ git checkout feature

$ git rebase master


Это перемещает всю функциональную ветку поверх основной путем переписывания истории проекта и создания новых коммитов для каждого коммита в исходной (функциональной) ветке.

Интерактивный ребейзинг

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


$ git checkout feature

$ git rebase -i master


Чтобы открыть редактор со списком всех коммитов, которые собираются переместить, используем:


pick 22d6d7c Commit message♯1

pick 44e8a9b Commit message♯2

pick 79f1d2h Commit message♯3


Это точно определяет, как будет выглядеть ветвь после выполнения перебазирования. Упорядочивая объекты, вы можете сделать историю такой, какой хотите. Например, вы можете использовать такие команды, как fixup, squash, edit и тд.

Так что же лучше?

По мере роста команды становится трудно управлять и отслеживать изменения. Чтобы иметь чистую и понятную историю коммитов очень удобно использовать rebase. Учитывая все вышеперечисленные преимущества и недостатки, можно получить максимум эффективности от rebase:

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

Код готов к рассмотрению. Другие рассматривают вашу работу и возможно загружают ее в свой форк. На этом этапе вы не должны перебазировать свою работу. Вы должны создавать коммиты-«переделки» и обновлять ветку. Это помогает отслеживать запросы и предотвращает случайную поломку истории.

Интеграция в целевую ветку. Поздравляю! Вы можете удалить функциональную ветку. Учитывая, что с этого момента другие разработчики не будут объединять эти изменения - это возможность очистить вашу историю. На этом этапе вы можете переписать историю и собрать исходные коммиты, pr rework и merge в небольшой набор целенаправленных коммитов. Создание явного слияния для этих коммитов необязательно, но в этом есть смысл. Оно записывает, когда побочная ветка превратилась в мастер.

Приятного кодинга!