В этой статье автор объясняет перебазирование с этой схемой:
Переоснова: Если Вы еще не опубликовали свое ответвление или ясно передали это, другие не должны основывать свою работу над ним, у Вас есть альтернатива. Можно повторно основывать ответвление, где вместо слияния, фиксация заменяется другой фиксацией с другим родителем, и ответвление перемещено туда.
в то время как нормальное слияние было бы похоже на это:
Так, если бы Вы повторно базируетесь, Вы просто теряете состояние истории (который был бы собран "мусор" когда-то в будущем). Так, почему кто-то хотел бы сделать переоснову вообще? Что я пропускаю здесь?
Есть множество ситуаций, в которых вы можете захотеть перебазировать.
Вы разрабатываете несколько частей функции в разных ветвях, а затем понимаете, что на самом деле они представляют собой линейное развитие идей. Восстановите их в этой конфигурации.
Вы создали ветку не в том месте. Возможно, это слишком рано (вам нужно что-то позже), может быть, уже слишком поздно (это действительно относится и к предыдущим версиям). Переместите его в нужное место. Случай «слишком поздно» на самом деле не может быть исправлен слиянием, поэтому перебазирование имеет решающее значение.
Вы хотите протестировать взаимодействие ветки с другой веткой, но по какой-то причине не хотите объединяться. Например, вы можете захотеть увидеть, какие конфликты возникают при каждой фиксации, а не все сразу.
Общая идея здесь заключается в том, что чрезмерное слияние загромождает историю, и перебазирование - это способ избежать этого, если вы сначала не получили правильный план ветвления / слияния. Слишком большое количество слияний может затруднить отслеживание истории человеком, а также затруднить использование таких инструментов, как git-bisect
.
Также существует множество случаев, когда требуется интерактивная перебазировка:
Множественные коммиты должны были быть одной фиксацией.
Фиксация (не текущая) должна была состоять из нескольких коммитов.
В коммите (не текущем) была ошибка в нем или в его сообщении.
Коммит (не текущий) должен быть удален.
Коммиты следует переупорядочить (например, чтобы они выполнялись более логично).
Хотя это правда, что вы «теряете историю», делая эти вещи, реальность такова, что вы хотите публиковать только чистую работу.Если что-то все еще не опубликовано, можно перебазировать это, чтобы преобразовать в то, как вы должны были зафиксировать это. Это означает, что окончательная версия в общедоступном репозитории будет логичной и простой в использовании, без каких-либо сбоев, которые были у разработчика на этом пути.
Rebasing позволяет вам подбирать слияния в правильном порядке. Теория, лежащая в основе слияния, говорит о том, что вы не должны беспокоиться об этом. Реальность разрешения сложных конфликтов становится проще, если вы делаете ребазинг, а затем сливаете новые изменения по порядку.
Возможно, вы захотите прочитать о Bunny Hopping