Git rebase: все, что вам нужно знать

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

Git-взрыв

Разочарованный другими системами контроля версий и их медленными обновлениями и фиксациями, Линус Торвальдс, известный по ядру Linux, в 2005 году выделил месяц, чтобы написать свою собственную. Он назвал его Гит.

Такие сайты, как GitHub, GitLab и BitBucket, совместно продвигали и извлекали выгоду из Git. Сегодня Git используется во всем мире: в опросе 2022 года 98% из 71 тысячи респондентов использовали Git в качестве системы контроля версий.

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

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

По мере завершения разработки в боковых ветвях изменения переносятся в основную ветку путем слияния ветки разработки с основной веткой. В других системах контроля версий работа с ветвями была сложной и требовательной к вычислительным ресурсам. Работа с ветками в Git очень быстрая и очень легкая. То, что когда-то было утомительным упражнением, которого часто избегали в других системах, в Git стало тривиальным.

Команда Git rebase — это еще один способ переноса изменений из одной ветки в другую. Команды merge и rebase имеют схожие цели, но они достигают своих целей разными способами и дают немного разные результаты.

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

Итак, для чего нужна команда Git merge ? Допустим, вы создали ветку под названием dev-branch для работы над новой функцией.

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

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

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

Теперь мы можем сказать Git, чтобы он объединил dev-branch с текущей веткой, которая является master веткой.

 git объединить ветку разработки 

Наше merge завершено для нас. Если вы извлечете master ветку и скомпилируете ее, в ней будет новая разработанная функция. На самом деле Git выполнил трехстороннее слияние. он сравнивает самые последние коммиты в ветках master и dev-branch , а также коммит в ветке master непосредственно перед созданием dev-branch . Затем он выполняет фиксацию в master ветке.

Слияния считаются неразрушающими, потому что они ничего не удаляют и не изменяют историю Git. dev-branch все еще существует, и ни один из предыдущих коммитов не изменен. Создается новая фиксация, фиксирующая результаты трехэтапного слияния.

После слияния наш репозиторий Git выглядит как временная шкала с ответвлением альтернативной линии, которая затем возвращается к основной временной шкале.

dev-branch branch включена в ветку master .

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

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

Обратите внимание: если у вас есть незафиксированные изменения в master ветке, вам нужно что-то сделать с этими изменениями, прежде чем вы сможете что-либо слить с ней. Вы можете создать новую ветку и зафиксировать там изменения, а затем выполнить слияние. Затем вам нужно будет объединить вашу временную ветку обратно в главную ветку.

Это работает, но в Git есть команда, которая делает то же самое, без необходимости создавать новые ветки. Команда stash сохраняет для вас ваши незафиксированные изменения и позволяет вам вызывать их с помощью stash pop .

Вы бы использовали их так:

 тайник

git объединить ветку разработки

тайник поп

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

Что такое ребаза Git?

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

Взяв наш предыдущий пример, до того, как мы выполнили какое-либо действие, наш репозиторий Git выглядит следующим образом. У нас есть ветка под названием dev-branch , и мы хотим перенести эти изменения в master ветку.

После rebase это выглядит как единая, полностью линейная временная шкала изменений.

dev-branch удалена, а коммиты из dev-branch добавлены в ветку master. Конечный результат такой же, как если бы коммиты в dev-branch были изначально непосредственно зафиксированы в ветке master . Коммиты не просто прикрепляются к master ветке, они «воспроизводятся» и добавляются свежими.

Вот почему команда rebase считается разрушительной. Перебазированная ветка больше не существует как отдельная ветка, а история Git вашего проекта была переписана. Позже вы не сможете определить, какие коммиты изначально были сделаны в dev-branch .

Тем не менее, это оставляет вас с упрощенной, линейной историей. По сравнению с репозиторием с десятками или даже сотнями веток и слияний, чтением журнала Git или использованием графического графического интерфейса git для просмотра графика репозитория, перебазированный репозиторий очень прост для понимания.

Как перебазировать на другую ветку

Давайте попробуем пример git rebase . У нас есть проект с веткой new-feature . Мы бы rebase эту ветку на master ветку следующим образом.

Во-первых, мы проверяем, что в ветке master нет невыполненных изменений.

 статус git

Мы проверяем ветку new-feature .

 git checkout новая функция

Мы говорим Git rebase текущую ветку на главную ветку.

 git мастер перебазирования

Мы видим, что у нас все еще есть две ветви.

 ветка git

Мы переключаемся обратно на ветку master

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

Мы объединяем ветку с новой функцией в текущую ветку, которая в нашем случае является master веткой.

 git слить новую функцию 

Интересно, что после финального слияния у нас остались две ветки.

Разница в том, что теперь заголовок ветки с new-feature и заголовок master ветки указывают на один и тот же коммит, а история Git не показывает, что раньше существовала отдельная ветка с new-feature , кроме ярлык филиала.

Git Rebase или Merge: что лучше использовать?

Это не случай rebase или merge . Это обе мощные команды, и вы, вероятно, будете использовать их обе. Тем не менее, есть случаи использования, когда rebase не работает так хорошо. Распаковывать ошибки, вызванные ошибками с помощью merge , неприятно, но распаковывать ошибки, вызванные rebase , — адски.

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

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

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

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

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

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

Перебазировать или не перебазировать?

Rebase может быть запрещен в вашем проекте. Могут быть местные, культурные возражения. Некоторые проекты или организации считают rebase формой ереси и актом осквернения. Некоторые люди считают, что история Git должна быть неприкосновенной, постоянной записью того, что произошло. Таким образом, rebase может быть исключено.

Но при локальном использовании в приватных ветках rebase — полезный инструмент.

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

Сделайте это, и вы избежите каких-либо проблем.

СВЯЗАННЫЕ С: Как проверить и обновить версию Git