Rebase - это Расширение Mercurial, позволяющее нам менять непропушенную часть дерева изменений в репозитории. Мы можем менять родителей непропушенных коммитов. В идеале мы должны получить вытянутую в одну линию цепочку изменений без ветвления в рамках одной ветки.
Как это работает
Когда мы хотим протолкнуть наш коммит, но обнаруживаем, что кто-то до нас успел протолкнуть что-то ещё, мы не сможем этого сделать, поэтому мы обновляемся и видим следующую картину:
Делая перебазирование нашего коммита, мы меняем родителся с “Пятый коммит” на “Чей-то коммит”, тем самым убирая ветвление:
Следует заметить, что происходит не перемещение коммита в другое место, а удаление и создание нового, это видно по тому, что изменяется идентификатор узла нашего коммита. В связи с этим возникает проблема при работе с подрепозиториями, о которой поведаем в следующем разделе.
На что следует обратить внимание
При использовании подрепозиториев, нам нужно внимательнее делать Rebase в них. Допустим, репозиторий ссылается на состояние С подрепозитория:
Мы перебазируем С на D и получаем ссылку на несуществующее состояние:
Если пропушить такое состояние репозитория, то потом при обновлении на это состояние будут возникать критичные ошибки, мешающие дальнейшей работе. Поэтому Rebase следует проводить последовательно начиная от самых глубоковложенных подрепозиториев и заканчивая корневыми. Эта проблема пропадает при использовании тонких репозиториев (описано в статье про подрепы).
Rebase или Merge?
Мы можем действовать стандартным способом и при возникновении подобных ситуаций делать слияние:
Но при большой команде разработки вскоре дерево принимает подобный вид:
В таком дереве двоичным поиском сложней найти сбойную ревизию, да и вообще трудно разобраться в последовательности изменений.
Итак, какой же способ ведения дерева нам выбрать? Если для нас критична история и действительное время коммитов, то мы используем Merge, если же для нас важна простота изучения истории и красота дерева, то выбираем Rebase.
Нужно отметить, что при многопользовательской правки одних и тех же файлов было замечено, что Rebase хуже справляется со слиянием, требуется больше времени, чтобы завершить все изменения.
Насколько Rebase должен упростить нам жизнь?
Какие положительные моменты данного подхода?
- Дерево выглядит красиво и понятно
- Удобно следить за историей изменений
- При необходимости двоичного поиска сбойной ревизии нам надо будет обновиться на меньшее количество ревизий, чем при сильно разветвлённом дереве
Какие отрицательные моменты?
- Потеря истории слияний, что иногда может привести к невозможности определения источника и виновника ошибки
- По опыту работы существуют отзывы, говорящие, что трудней проводить громоздкие слияния с Rebase, чем при использовании обычных слияний
Как мы можем обойтись без Rebase?
В принципе, можно сохранить прямое дерево изменений, если перед каждым коммитом обновляться на последнюю ревизию, улаживать конфликты, коммитить и сразу проталкивать изменения. Я сам так всегда делал до того, как узнал про Rebase.
Конечно же, есть положительные и отрицательные стороны подхода:
Положительные:
- Мы-таки сохраняем дерево стройным и красивым
Отрицательные:
- При неудачном слиянии можно безвозвратно потерять свои незакоммиченные изменения
- Не получится разбить задачу на несколько коммитов, сохранив их рядом друг с другом
Хочу отметить, что если задача состоит из нескольких коммитов и имеет довольно большой срок разработки (больше недели), то следует создать отдельную ветку для реализации и потом слить её с рабочей веткой, чтобы обособить масштабные изменения от других правок.
