git-rebase - Повторное применение коммитов над верхушкой другой ветки

Пересаживает серию коммитов на другую начальную точку. Вы также можете использовать git rebase для переупорядочивания или объединения коммитов: см. ИНТЕРАКТИВНЫЙ РЕЖИМ ниже о том, как это сделать.

Например, представьте, что вы работали над веткой topic в этой истории и хотите «догнать» работу, выполненную в ветке master.

Вы хотите пересадить коммиты, которые вы сделали в topic с момента её ответвления от master (т.е. A, B и C), поверх текущего master. Вы можете сделать это, выполнив git rebase master, пока переключена ветка topic. Если вы хотите переместить topic, находясь на другой ветке, git rebase master topic — это краткая форма для git checkout topic && git rebase master.

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

Если вы не указываете <вышестоящую-ветку> для перемещения на неё, будет использоваться вышестоящая ветка, настроенная в параметрах branch.<имя>.remote и branch.<имя>.merge (подробности см. в git-config[1]), и предполагается параметр --fork-point. Если вы в настоящее время не находитесь ни на какой ветке или если текущая ветка не имеет настроенной вышестоящей, перемещение будет прервано.

Вот упрощённое описание того, что делает git rebase <вышестоящая-ветка>:

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

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

Мы хотим, чтобы topic была ответвлена от ветки master; например, потому что функциональность, от которой зависит topic, была слита в более стабильную ветку master. Мы хотим, чтобы наше дерево выглядело так:

Мы можем получить это с помощью следующей команды:

Другой пример параметра --onto — перемещение части ветки. Если у нас есть следующая ситуация:

затем команда

приведёт к:

Это полезно, когда topicB не зависит от topicA.

Диапазон коммитов также может быть удалён с помощью перемещения. Если у нас есть следующая ситуация:

затем команда

приведёт к удалению коммитов F и G:

Это полезно, если F и G были каким-то образом ошибочны или не должны быть частью topicA. Обратите внимание, что аргумент --onto и параметр <вышестоящая-ветка> могут быть любым допустимым указателем коммита.

Параметры в этом разделе нельзя использовать с любыми другими параметрами, включая друг друга:

Примеры см. в разделе ПЕРЕСАДКА ТЕМАТИЧЕСКОЙ ВЕТКИ С ПОМОЩЬЮ --ONTO выше.

Следующие параметры:

несовместимы со следующими параметрами:

Кроме того, следующие пары параметров несовместимы:

git rebase имеет два основных внутренних механизма: apply и merge. (Механизм apply ранее был известен как механизм am, но это название вызывало путаницу, поскольку оно выглядит как глагол, а не существительное. Кроме того, механизм merge ранее был известен как интерактивный механизм, но теперь он также используется для неинтерактивных случаев. Оба были переименованы на основе низкоуровневой функциональности, лежащей в основе каждого.) Существуют некоторые тонкие различия в поведении этих двух внутренних механизмов:

Механизм слияния (команды git merge и git pull) позволяет выбирать внутренние стратегии слияния с помощью параметра -s. Некоторые стратегии также могут принимать свои собственные параметры, которые можно передать, указав аргументы -X<параметр> для git merge и/или git pull.

Со стратегиями, использующими трёхходовое слияние (включая стратегию по умолчанию, ort), если изменение вносится в обе ветки, но позже отменяется в одной из веток, это изменение будет присутствовать в результате слияния; некоторые люди находят такое поведение запутанным. Это происходит потому, что при выполнении слияния учитываются только головы и основа слияния, а не отдельные коммиты. Поэтому алгоритм слияния считает отменённое изменение вообще отсутствием изменения и вместо него подставляет изменённую версию.

Вы должны понимать последствия использования git rebase в репозитории, которым вы делитесь. См. также ВОССТАНОВЛЕНИЕ ПОСЛЕ ПЕРЕМЕЩЕНИЯ ВЫШЕСТОЯЩЕЙ ВЕТКИ ниже.

При запуске перемещения сначала будет выполнен перехватчик pre-rebase, если он существует. Вы можете использовать этот перехватчик для выполнения проверок работоспособности и отклонения перемещения, если оно неуместно. Пожалуйста, обратитесь к шаблону сценария перехватчика pre-rebase для примера.

По завершении <ветка> станет текущей веткой.

Интерактивное перемещение означает, что у вас есть возможность редактировать коммиты, которые перемещаются. Вы можете переупорядочить коммиты и удалить их (отсеивая плохие или иным образом нежелательные патчи).

Интерактивный режим предназначен для такого типа рабочего процесса:

где пункт 2. состоит из нескольких экземпляров

a) обычное использование

b) независимое исправление

Иногда исправление, сделанное в б.2., не может быть добавлено к не совсем идеальному коммиту, который оно исправляет, потому что этот коммит глубоко похоронен в серии патчей. Именно для этого и нужно интерактивное перемещение: используйте его после множества "а" и "б", переставляя и редактируя коммиты и объединяя несколько коммитов в один.

Начните его с последнего коммита, который вы хотите сохранить как есть:

Будет запущен редактор со всеми коммитами в вашей текущей ветке (игнорируя коммиты слияния), которые идут после указанного коммита. Вы можете переупорядочить коммиты в этом списке по своему усмотрению и удалить их. Список выглядит примерно так:

Однострочные описания предназначены исключительно для вашего удобства; git rebase не будет смотреть на них, а на имена коммитов ("deadbee" и "fa1afe1" в этом примере), поэтому не удаляйте и не редактируйте имена.

Заменив команду «pick» командой «edit», вы можете указать git rebase остановиться после применения этого коммита, чтобы вы могли отредактировать файлы и/или сообщение коммита, исправить коммит и продолжить перемещение.

Чтобы прервать перемещение (как это сделала бы команда "edit", но без предварительного копирования какого-либо коммита), используйте команду "break".

Если вы просто хотите отредактировать сообщение коммита, замените команду «pick» командой «reword».

Чтобы удалить коммит, замените команду «pick» на «drop» или просто удалите соответствующую строку.

Если вы хотите объединить два или более коммитов в один, замените команду "pick" для второго и последующих коммитов на "squash" или "fixup". Если у коммитов были разные авторы, объединённый коммит будет приписан автору первого коммита. Предлагаемое сообщение коммита для объединённого коммита представляет собой объединение сообщения первого коммита с сообщениями, идентифицированными командами "squash", опуская сообщения коммитов, идентифицированных командами "fixup", если только не используется "fixup -c". В этом случае предлагаемое сообщение коммита — это только сообщение коммита "fixup -c", и открывается редактор, позволяющий вам отредактировать сообщение. Содержимое (патч) коммита "fixup -c" по-прежнему включается в объединённый коммит. Если существует более одного коммита "fixup -c", используется сообщение последнего. Вы также можете использовать "fixup -C", чтобы получить то же поведение, что и "fixup -c", но без открытия редактора.

git rebase остановится, когда «pick» будет заменён на «edit» или когда команда завершится ошибкой из-за конфликтов слияния. Когда вы закончите редактирование и/или разрешение конфликтов, вы можете продолжить с помощью git rebase --continue.

Например, если вы хотите переупорядочить последние 5 коммитов так, чтобы то, что было HEAD~4, стало новым HEAD. Чтобы добиться этого, вы должны вызвать git rebase следующим образом:

И переместить первый патч в конец списка.

Вы можете захотеть воссоздать коммиты слияния, например, если у вас есть такая история:

Предположим, вы хотите переместить побочную ветку, начинающуюся с "A", на "Q". Убедитесь, что текущий HEAD — "B", и вызовите

Переупорядочение и редактирование коммитов обычно создаёт непроверенные промежуточные шаги. Вы можете захотеть проверить, что ваше редактирование истории ничего не сломало, запустив тест или, по крайней мере, перекомпилируя в промежуточных точках истории, используя команду "exec" (сокращённо "x"). Вы можете сделать это, создав список задач, подобный этому:

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

Команда "exec" запускает команду в оболочке (по умолчанию, обычно /bin/sh), поэтому вы можете использовать возможности оболочки (например, "cd", ">", ";" …​). Команда запускается из корня рабочего каталога.

Эта команда позволяет вам проверить, что промежуточные коммиты компилируются. Список задач становится таким:

В интерактивном режиме вы можете помечать коммиты действием "edit". Однако это не обязательно означает, что git rebase ожидает, что результатом этого редактирования будет ровно один коммит. Действительно, вы можете отменить коммит или добавить другие коммиты. Это можно использовать для разделения коммита на два:

Если вы не абсолютно уверены, что промежуточные редакции согласованы (они компилируются, проходят набор тестов и т.д.), вам следует использовать git stash, чтобы спрятать ещё не зафиксированные изменения после каждого коммита, протестировать и исправить коммит, если необходимы исправления.

Перемещение (или любая другая форма переписывания) ветки, на которой другие основали свою работу, — плохая идея: любой, кто находится ниже по течению, вынужден вручную исправлять свою историю. В этом разделе объясняется, как выполнить исправление с точки зрения нижестоящего. Однако настоящее исправление состоит в том, чтобы вообще избегать перемещения вышестоящей ветки.

Для иллюстрации предположим, что вы находитесь в ситуации, когда кто-то разрабатывает ветку subsystem, а вы работаете над topic, которая зависит от этого subsystem. В итоге у вас может получиться история, подобная следующей:

Если subsystem перемещается относительно master, происходит следующее:

Если вы теперь продолжите разработку как обычно и в конечном итоге сольёте topic в subsystem, коммиты из subsystem останутся продублированными навсегда:

Такие дубликаты обычно не одобряются, поскольку они загромождают историю, затрудняя её понимание. Чтобы очистить ситуацию, вам нужно пересадить коммиты на topic на новую верхушку subsystem, т.е. переместить topic. Это вызывает эффект ряби: любой, кто находится ниже по течению от topic, также вынужден выполнять перемещение, и так далее!

Существует два вида исправлений, обсуждаемых в следующих подразделах:

Команда интерактивного перемещения изначально была разработана для обработки отдельных серий патчей. Как таковая, она исключает коммиты слияния из списка задач, поскольку разработчик мог слить тогдашний master во время работы над веткой, чтобы в конечном итоге переместить все коммиты на master (пропуская коммиты слияния).

Однако существуют законные причины, по которым разработчик может захотеть воссоздать коммиты слияния: чтобы сохранить структуру ветвления (или "топологию коммитов") при работе с несколькими взаимосвязанными ветками.

В следующем примере разработчик работает над тематической веткой, которая рефакторит способ определения кнопок, и над другой тематической веткой, которая использует этот рефакторинг для реализации кнопки "Сообщить об ошибке". Вывод git log --graph --format=%s -5 может выглядеть так:

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

Это перемещение может быть выполнено с использованием параметра --rebase-merges. Он сгенерирует список задач, выглядящий так:

В отличие от обычного интерактивного перемещения, здесь есть команды label, reset и merge в дополнение к командам pick.

Команда label связывает метку с текущим HEAD, когда эта команда выполняется. Эти метки создаются как ссылки, локальные для рабочего каталога (refs/rewritten/<метка>), которые будут удалены после завершения перемещения. Таким образом, операции перемещения в нескольких рабочих каталогах, связанных с одним и тем же репозиторием, не мешают друг другу. Если команда label завершается ошибкой, она немедленно перепланируется с полезным сообщением о том, как продолжить.

Команда reset сбрасывает HEAD, индекс и рабочий каталог на указанную редакцию. Она похожа на exec git reset --hard <метка>, но отказывается перезаписывать неотслеживаемые файлы. Если команда reset завершается ошибкой, она немедленно перепланируется с полезным сообщением о том, как отредактировать список задач (обычно это происходит, когда команда reset была вставлена в список задач вручную и содержит опечатку).

Команда merge сольёт указанную(ые) редакцию(и) в то, что является HEAD в этот момент. С -C <исходный-коммит> будет использовано сообщение коммита указанного коммита слияния. Когда -C изменён на строчный -c, сообщение будет открыто в редакторе после успешного слияния, чтобы пользователь мог отредактировать сообщение.

Если команда merge завершается ошибкой по любой причине, кроме конфликтов слияния (т.е. когда операция слияния даже не начиналась), она немедленно перепланируется.

По умолчанию команда merge будет использовать стратегию слияния ort для обычных слияний и octopus для слияний-осьминогов. Можно указать стратегию по умолчанию для всех слияний, используя аргумент --strategy при вызове rebase, или можно переопределить конкретные слияния в интерактивном списке команд, используя команду exec для явного вызова git merge с аргументом --strategy. Обратите внимание, что при явном вызове git merge таким образом вы можете использовать тот факт, что метки являются ссылками, локальными для рабочего каталога (ссылка refs/rewritten/onto будет соответствовать метке onto, например), чтобы ссылаться на ветки, которые вы хотите слить.

Примечание: первая команда (label onto) помечает редакцию, на которую перемещаются коммиты; имя onto — это всего лишь соглашение, как намёк на параметр --onto.

Также можно ввести совершенно новые коммиты слияния с нуля, добавив команду вида merge <голова-слияния>. Эта форма сгенерирует предварительное сообщение коммита и всегда откроет редактор, чтобы пользователь мог его отредактировать. Это может быть полезно, например, когда тематическая ветка решает более одной задачи и её нужно разделить на две или даже более тематических веток. Рассмотрим этот список задач:

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

Дальнейшее содержание этого раздела, повторяет то, что может быть найдено в git-config[1]:

Является частью пакета git[1]