Чем опасен pull --rebase для локальной ветки?

Question

[alex4answ]

Доброе утро, чем опасен git pull --rebase для локальной ветки?

Использую git-flow где для каждой фичи - отдельная ветка, в которой работает только 1 человек.
При обновлении мастера, нужно обновить и эту локальную ветку, сейчас я это делаю в *dev git pull origin & git merge master

Но хотелось бы rebase, чтобы мои изменения были сверху тех, что уже закомичены в master, но читал что так делать не стоит, но когда ты работаешь над веткой 1 - почему нет?

Понятное дело потом эта ветка будет отправлена в origin и в дальнейшем слита с master

Comments

[Максим Грищенко]

Над своей фича-веткой ребейз можно (нужно) делать — он удобен и чисто все делает.

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

В мастере или деве rebase должен быть запрещен

[Сергей Кузнецов]

Если ты работаешь в тематической ветке один, то git pull --rebase вообще бесполезен и ничего не сделает, как и обычный git pull, который 'эквивалентен git fetch & git merge

Но подозреваю, что ты имел в виду замену второй операции git merge master на git rebase master?

[alex4answ]

Сергей Кузнецов, да, я имел ввиду сначала pull мастера, затем rebase моей ветки с master

[Сергей Кузнецов]

alex4answ, ты написал две команды через &, значит обе команды выполняются последовательно в одной ветке. Не вижу тут переключения на другую ветку.

Если ты выполняешь это в мастере, то во первых без разницы в каком режиме работает pull, там в любом случае будет fast-forward. Во вторых, вторых вторая команда становится бессмысленной. Зачем сливать мастер с самим собой?

Если ты в тематической ветке, то первая часть команды бессмысленна, так как ничего не произойдёт. А вторая команда зависит от того, чего ты хочешь увидеть. Можно создать коммит слияния (git merge master --no-fast-forward) чтобы гарантировать последующее сливание тематической ветки в мастер без конфликтов, либо перестроить твою тематическую ветку на вершине мастера (git rebase master). Всё зависит от ваших рабочих процессов в команде. Мне больше нравится второй вариант, так как в первом будет уже сложно переписать твои готовые коммиты.

[alex4answ]

Сергей Кузнецов, Да, я +- разобрался как это работает, сейчас перечитываю githowto
В итоге когда задавал вопрос и сам запутался и все запутал.

Пришел к тому, что нужно сначала обновить мастер git pull origin (*master), затем перейти на тематическую ветку и выполнить там git rebase master

Спасибо)

[Макс]

Тоже долго прыгал по веткам а потом открыл для себя: git pull --rebase origin master. Вызывать в ветке, которую нужно на мастер отребейзить.

Answer 1

[Сергей Кузнецов]

При обновлении мастера, нужно обновить и эту локальную ветку, сейчас я это делаю в *dev

git switch master & git pull & git switch - & git merge master

Зачем усложняете? Достаточно одной команды
git pull origin master

читал что так делать не стоит

Эти писатели сами не понимают что пишут. Если тематическая ветка короткоживущая, то наоборот лучше не засорять её коммитами слияния, а каждый раз лучше пересаживать на вершину мастера.
git pull --rebase origin master

А ещё можно задать глобальный параметр
git config --global pull.rebase true
И тогда простой pull сразу будет делать rebase без отдельных напоминаний