Понимание основ Git Rebase

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

Ознакомьтесь с официальной документацией git для более глубокого технического понимания того, как это работает: https://git-scm.com/docs/git-rebase

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

Git rebase может вам помочь! Не испортив свою историю git!!

А как насчет `git merge`?

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

Вы проверили свою функциональную ветку и запустили git merge master — и вуаля! В вашей ветке теперь есть последние обновления от master.

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

- Объединить запрос на вытягивание #123 из проекта/мастера
- Объединить запрос на вытягивание #124 из проекта/мастера
- feat(Component): создать новый компонент
- Объединить запрос на вытягивание #125 из проекта/ владелец

Хотя выполнить слияние git проще, это будет происходить за счет качества вашей истории git.

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

Некоторые примеры

Прежде чем мы начнем…

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

Если вы предпочитаете использовать другой подход к организации ваших филиалов. Например, git-flow, где вы используете ветку develop для своих функций вместо master. эти шаги по-прежнему помогут вам с тем, что вам нужно. Вам просто нужно заменить master на develop (или любую другую ветку, которую вы хотите использовать).

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

Предположим, у нас есть ветвь master, ветвь feature и, возможно, ветвь other-feature:

СЦЕНАРИЙ 1 :: Моя особенность - несколько коммитов за `master`. Я хочу обновить свою ветку функций с последними изменениями в master.

feature включает коммиты A и B, но не C и D. Коммиты C и D были созданы в какой-то момент после создания ветки feature.

Я хочу, чтобы ветвь feature включала коммиты C и D до того, как я солью свою ветвь с master, чтобы я мог убедиться, функция работает с текущим состоянием master:

СЦЕНАРИЙ 2 :: Моя функция была ответвлением от другой ветки функций. Я хочу изменить это, чтобы вместо этого моя функция начиналась с главной ветки.

feature включает в себя как A, B, E, так и Fфиксирует, но не C и D. Коммиты C и D были созданы в какой-то момент после создания ветки other-feature и, возможно, задолго до создания ветки feature. .

Я хочу, чтобы feature основывалось непосредственно на master, а не на other-feature. Мне не нужны коммиты E и F в моей ветке, а вместо этого я хочу основывать feature на master, и включить коммиты C и D:

Цель обоих сценариев одна и та же — мы хотим, чтобы функция имела все последние обновления от master и только master с чистой историей git feature.

Подготовка к перебазированию (`master`)

беги git checkout master
запустите git pull, чтобы получить последние изменения с удаленного
запустите npm test, чтобы убедиться, что тесты проходят.
Если ваши тесты не работают здесь, на master, рекомендуется решить эти проблемы до того, как вы перебазируете feature на master.

Подготовка к перебазированию (`feature`)

беги git checkout feature
запустите git pull, чтобы получить последние изменения с удаленного компьютера

Найдите общего предка с `master` с помощью git-merge-base

беги git checkout feature
запустите git merge-base master feature, чтобы найти самую последнюю фиксацию, общую для обеих ветвей.
Это создаст длинную строку идентификатора коммита, которая выглядит примерно так: abcdef1234567890abcdef.

Запустите git-rebase

ПРИМЕЧАНИЕ. Если у вас возникнут какие-либо проблемы, вы можете запуститьgit rebase --abort, чтобы отменить весь процесс. Перебазирование может быть мгновенным, если конфликты не обнаружены, но если вы перебазируете ветку функций, в которой отсутствуют десятки/сотни или коммиты от мастера, ожидайте длительного процесса исправления конфликтов.
беги git rebase --onto master abcdef1234567890abcdef. Замените длинную строку идентификатора строкой идентификатора, сгенерированной на вашей стороне.
Если обнаружены конфликты, разрешите все файлы и запустите git add ., когда закончите, чтобы внести изменения. Затем запустите git rebase --continue, чтобы продолжить процесс.
В конце концов процесс завершится, и ваша ветка feature теперь будет содержать чистую запись со всеми последними данными из master.
Если ваша предварительно перебазированная ветка была отправлена в восходящий поток, вам нужно будет запустить git push --force, чтобы перезаписать предварительно перебазированную ветку новой чистой перебазированной веткой.

Заключение

В прошлом я работал над многими проектами, где использование git использовалось немногим больше, чем stage->commit->push и merge, без учета качества истории git проекта. Git становится бесполезным инструментом для отладки, он ничего не говорит об истории проекта и приводит к постепенному замедлению разработки с течением времени…

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

Понимание основ Git Rebase