Доброе утро, чем опасен git pull --rebase для локальной ветки?
Использую git-flow где для каждой фичи - отдельная ветка, в которой работает только 1 человек.
При обновлении мастера, нужно обновить и эту локальную ветку, сейчас я это делаю в *dev git pull origin & git merge master
Но хотелось бы rebase, чтобы мои изменения были сверху тех, что уже закомичены в master, но читал что так делать не стоит, но когда ты работаешь над веткой 1 - почему нет?
Понятное дело потом эта ветка будет отправлена в origin и в дальнейшем слита с master
Над своей фича-веткой ребейз можно (нужно) делать — он удобен и чисто все делает.
Не удобно может при сложном процессе ревью, тк у ревьюеров сбрасывает точку изменений и весь ваш PR по сути одно изменение... мало ли вы туда чего добавили опять
Если ты работаешь в тематической ветке один, то git pull --rebase вообще бесполезен и ничего не сделает, как и обычный git pull, который 'эквивалентен git fetch & git merge
Но подозреваю, что ты имел в виду замену второй операции git merge master на git rebase master?
alex4answ, ты написал две команды через &, значит обе команды выполняются последовательно в одной ветке. Не вижу тут переключения на другую ветку.
Если ты выполняешь это в мастере, то во первых без разницы в каком режиме работает pull, там в любом случае будет fast-forward. Во вторых, вторых вторая команда становится бессмысленной. Зачем сливать мастер с самим собой?
Если ты в тематической ветке, то первая часть команды бессмысленна, так как ничего не произойдёт. А вторая команда зависит от того, чего ты хочешь увидеть. Можно создать коммит слияния (git merge master --no-fast-forward) чтобы гарантировать последующее сливание тематической ветки в мастер без конфликтов, либо перестроить твою тематическую ветку на вершине мастера (git rebase master). Всё зависит от ваших рабочих процессов в команде. Мне больше нравится второй вариант, так как в первом будет уже сложно переписать твои готовые коммиты.
