Да, если после команды git rebase origin/main получили конфликты, то после их решения новые коммты могут заметно отличаться. Но прелесть rebase в том, что при его проведении гит будет просить (в дефолтном редакторе) поправить конфликты в каждом из коммитов feature-ветки (если они есть). При проведение rebase git переходит в специальное состояние rebase, если ввести команду git status, то в терминале будет что-то вроде "rebase in progress". В этом состоянии нам доступны еще три команды
git rebase --continue
git rebase --skip
git rebase --abort
То есть после решения конфликта вводим git rebase --continue и git перескакивает к следующему коммиту.
Если не уверен что rebase был правильной идеей, то можно вернуться на состояние до rebase с помощью git rebase --abort.
Если выполнил rebase, но есть необходимость вернуться в состояние до него и получить предыдущий код, то пользуемся git reflog, для того, чтобы найти указатель HEAD до rebase. При вводе комманды git reflog вывод будет примерно такой
abc9999 HEAD@{0}: rebase (finish): returning to refs/heads/feature
def8888 HEAD@{1}: rebase (pick): feat: add validation
ghi7777 HEAD@{2}: rebase (pick): feat: add api integration
jkl6666 HEAD@{3}: rebase (start): checkout main
mno5555 HEAD@{4}: commit: feat: add api integration
pqr4444 HEAD@{5}: commit: feat: add validation
stu3333 HEAD@{6}: checkout: moving from main to feature
Здесь видно, где был HEAD на каждом этапе, мы можем перескочить в любое состояние, например выполняем git reset --hard HEAD@{4} и это будут ровно то состояние ветки, когда были актуальны коммиты D и E
Привет! Согласен, это один из главных минусов rebase. Я постарался в статье как раз разобрать этот минус. В общих ветках использовать rebase лучше очень осторожно или вообще не использовать, а предпочитать merge.
Но во feature-ветках, когда ты работаешь в ней один - риски использовать rebase минимальны. Гит предоставляет инструменты git reflog и git reset, которые позволят тебе откатиться к любому состоянию в прошлом, даже до момента rebase.
Для меня rebase это не замена merge, а инструмент, который позволяет держать историю в чистоте до слияния с main, но нужно учитывать риски обязательно.
Да, спасибо большое за замечание, действительно нужно было вставить что-то про решение конфиликтов
Да, если после команды git rebase origin/main получили конфликты, то после их решения новые коммты могут заметно отличаться. Но прелесть rebase в том, что при его проведении гит будет просить (в дефолтном редакторе) поправить конфликты в каждом из коммитов feature-ветки (если они есть). При проведение rebase git переходит в специальное состояние rebase, если ввести команду git status, то в терминале будет что-то вроде "rebase in progress". В этом состоянии нам доступны еще три команды
То есть после решения конфликта вводим git rebase --continue и git перескакивает к следующему коммиту.
Если не уверен что rebase был правильной идеей, то можно вернуться на состояние до rebase с помощью git rebase --abort.
Если выполнил rebase, но есть необходимость вернуться в состояние до него и получить предыдущий код, то пользуемся git reflog, для того, чтобы найти указатель HEAD до rebase. При вводе комманды git reflog вывод будет примерно такой
Здесь видно, где был HEAD на каждом этапе, мы можем перескочить в любое состояние, например выполняем git reset --hard HEAD@{4} и это будут ровно то состояние ветки, когда были актуальны коммиты D и E
Привет!
Согласен, это один из главных минусов rebase. Я постарался в статье как раз разобрать этот минус. В общих ветках использовать rebase лучше очень осторожно или вообще не использовать, а предпочитать merge.
Но во feature-ветках, когда ты работаешь в ней один - риски использовать rebase минимальны. Гит предоставляет инструменты git reflog и git reset, которые позволят тебе откатиться к любому состоянию в прошлом, даже до момента rebase.
Для меня rebase это не замена merge, а инструмент, который позволяет держать историю в чистоте до слияния с main, но нужно учитывать риски обязательно.