Rebase - одна из самых мощных команд Git
Когда программист впервые изучает git, типичные команды, которые выбираются, включают add, commit, push, pull, status, branch, checkout и merge. Я думаю, что после изучения этих основных команд следует понять команду rebase.
Ребазинг часто используется как альтернатива слиянию. При обновлении ветки одна ветка обновляется другой путем применения коммитов одной ветки поверх коммитов другой ветки. Например, если вы работаете с веткой feature, которая устарела с веткой dev, перенастройка ветки feature на dev позволит включить все новые коммиты из dev в feature. Вот как это выглядит визуально:
В приведенном выше примере это будет выглядеть так из командной строки:
git rebase feature dev
Однако чаще всего сначала проверяют ветку, а затем запускают команду rebase с именем ветки, на которую вы хотите перебазировать:
git checkout feature git rebase dev
Типичные варианты использования Rebase
Обновление функциональной ветви
Допустим, вы работаете feature в филиале, заботясь о собственном бизнесе.
Затем вы замечаете несколько новых коммитов на dev, которые вы хотели бы иметь в своей ветке функции, поскольку новые коммиты могут повлиять на то, как вы реализуете эту функцию.
Вы решили запустить git rebase dev из своей feature ветки, чтобы получить последнюю версию dev.
Однако, когда вы запускаете команду rebase, возникают конфликты между изменениями, внесенными вами в feature, и новыми фиксациями dev. К счастью, процесс перебазирования проходит через каждую фиксацию по одному, и поэтому, как только он замечает конфликт в фиксации, git предоставит сообщение в терминале с указанием, какие файлы необходимо разрешить. После разрешения конфликта вы git add вносите изменения в фиксацию и запускаете git rebase --continue, чтобы продолжить процесс перебазирования. Если конфликтов больше нет, вы успешно перебазируете ветку feature на dev.
Теперь вы можете продолжить работу над своей функцией, используя последние коммиты от dev, включенные в feature, и в мире снова все хорошо. Этот процесс может повториться, если ветка dev будет обновлена дополнительными коммитами.
Обновление функциональной ветви перед слиянием
Еще одно популярное применение перебазирования - это перебазирование ветки feature непосредственно перед слиянием с веткой dev. Допустим, текущее состояние веток feature и dev выглядит следующим образом:
Когдаfeature будет завершено, его следует объединить с ветвью dev. Во-первых, веткуfeature следует обновить на dev, используя git rebase dev.
Затем слейте feature в dev. Обычно это делается с помощью запроса на слияние, чтобы другие могли просмотреть работу, проделанную в ветке feature. Как только это будет сделано, результат будет следующим:
Обратите внимание, как все коммиты из ветки feature добавляются в конец ветки dev. Так будет всегда, если перебазирование выполняется непосредственно перед слиянием. Причина, по которой это происходит, заключается в том, что при перезагрузке перезаписывает историю git, и поэтому временная метка коммитов в перебазированной ветке будет моментом, когда была запущена команда rebase. Чтобы было ясно, перезапись истории с помощью rebase воссоздает коммиты, которые содержат те же изменения и сообщение о фиксации, но с новым хешем и меткой времени. Следовательно, при объединении недавно перебазированной ветки feature в dev все фиксации ветки feature будут добавлены в конец dev, поскольку слияние заказов фиксируется в хронологическом порядке.
На самом деле в Github есть опция Pull Requests для перебазирования ветки перед слиянием.
Переименование и объединение коммитов в функциональных ветках
Скорее всего, когда функция в ветке feature приближается к завершению, историю коммитов можно улучшить, переименовав некоторые коммиты во что-то более подходящее, объединив тесно связанные коммиты и / или переупорядочив коммиты в более логичном порядке. Ребазинг позволяет все это!
Поскольку при перебазировании перезаписывается история git, он предоставляет некоторые инструменты, позволяющие точно указать, как перезаписать историю. Лучший способ воспользоваться преимуществами этих дополнительных функций перебазирования - запустить перебазирование в интерактивном режиме, передав флаг -i с командой (т. Е. git rebase -i feature dev).
При запуске интерактивной перебазировки список коммитов, которые будут перебазированы вместе со словом pick в начале каждого сообщения о коммите, представлен в редакторе git по умолчанию, настроенном на вашем компьютере (в моем случае это Код Visual Studio). Слово pick можно изменить с помощью любой из следующих опций (все они перечислены при запуске интерактивной перебазировки):
pick = use commit
reword = use commit, but edit the commit message
edit = use commit, but stop for amending
squash = use commit, but meld into previous commit
fixup = like "squash", but discard this commit's log message
exec = run command (the rest of the line) using shell
drop = remove commitДля примеров, упомянутых ранее, вот как вы можете с ними справиться:
- Сообщение о фиксации можно переформулировать, используя параметр
rewordдля фиксации. - Объединение коммитов выполняется с помощью параметра
squashилиfixupв коммите, который должен быть объединен с другим коммитом. Убедитесь, что фиксация, указанная с помощью _59 _ / _ 60_, сразу следует за фиксацией, с которой ее следует объединить. - Переупорядочить коммиты так же просто, как переместить сообщения коммитов в желаемом порядке.
Что такого хорошего в ребасинге?
Нет коммитов слиянием
Слияние двух веток всегда требует фиксации слияния. Если функциональная ветка постоянно обновляется веткой dev с использованием слияния, произойдет несколько коммитов слияния, что приведет к менее четкой истории git.
Эти коммиты слияния могут быть полностью устранены, если для обновления ветки feature вместо слияния используется перебазирование.
Линейная и последовательная история Git
При перебазировании ветки перед слиянием все коммиты ветки feature группируются вместе в конце ветви dev, тогда как коммиты ветки feature перемежаются в ветке dev, если перебазирование не используется до слияния. Это потому, что слияние заказов фиксируется в хронологическом порядке. Функция группировки коммитов вместе, как в случае с перебазированием, упрощает понимание / анализ истории git впоследствии.
Более простое разрешение конфликтов
При перебазировании git применяет каждую фиксацию по одному, поэтому конфликты могут разрешаться постепенно. При разрешении конфликтов для слияния все конфликты должны быть разрешены сразу, что может немного усложнить их обработку.
Если во время перенастройки возникает конфликт, git укажет, какие файлы конфликтуют и должны быть изменены. После того, как изменения были внесены, их необходимо подготовить к фиксации, а затем перебазирование можно возобновить с помощью git rebase --continue. Также есть возможность запустить git rebase --abort при разрешении конфликтов в перебазировании, что отменит перебазирование и оставит ветвь без изменений.
Хорошо организованная и чистая история Git
Благодаря всем вышеперечисленным преимуществам, помимо возможности изменять сообщения коммитов, комбинировать коммиты и переупорядочивать коммиты, перебазирование обеспечивает очень чистую историю git, которую легко понять. Иметь понятную историю git - это здорово, когда вы пытаетесь определить, когда в вашу кодовую базу была добавлена определенная функция или ошибка.
Когда не перебазировать
Хорошо, перебазирование - это довольно мило, но, безусловно, есть случаи, когда перебазировать не следует. Золотое правило перебазирования - не перебазировать публичные ветки. Причина, по которой вы не должны перебазировать общедоступную ветку, заключается в том, что вы переписываете историю git для этой ветки, и это приведет к тому, что ваша версия общедоступной ветки будет отличаться от версии, с которой работают другие пользователи. Это приведет к множеству конфликтов и может оказаться утомительной проблемой для решения после того, как это будет сделано, поэтому убедитесь, что переназначены только те ветки, над которыми вы, и только вы работаете .
Добавление git rebase в рабочий процесс git может быть чрезвычайно ценным способом очистки истории git и облегчения работы с общим рабочим процессом git. Способ работы rebase может поначалу быть не совсем интуитивным, но после использования этой команды несколько раз в ветках функций, чтобы лучше ознакомиться с ней, вы, надеюсь, в конечном итоге увидите некоторые из преимуществ, упомянутых в этой статье.
