Git: объясните «на пальцах» разницу между rebase и cherry-pick?

С августа начал активно использовать git в рабочих и личных проектах. Началось все с тотального непонимания и ненависти, постепенно пришел к любви и восхищению.

Изучил официальный учебник, прочитал и попробовал или уже внедрил много хороших практик и, неочевидных после SVN, workflow. Чувствую себя спокойно и уверенно с гитом, но как-то до сих пор не смог осознать разницу между rebase и cherry-pick. Вроде и та и другая команды грубо говоря берут оттуда и суют сюда. Одни и те же задачи из своего повседневного рациона можно сделать как с помощью одной, так и с помощью другой. Но не дает покоя мысль, что не зря они разные и я что-то упускаю. Учебник не помогает, гугл не спасает.

Помогите разобраться в отличиях. Может есть какие-то специфичные примеры, на которых разница будет отчетливо заметна.
  • Вопрос задан
  • 112725 просмотров
Пригласить эксперта
Ответы на вопрос 3
Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.

git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
(ветка devel "растворяется" в основной ветке)
518b8dbce1cd4f96b30de9782ae38fcd.png
git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)
1ba8186d879d46ff85ea7c1e192328e2.png
git chery-pick idea - забрать коммиты из ветки idea
2717e3091f644ef2954aa2de4514f446.png
Ответ написан
@Nkly777
git chery-pick - ты забираешь комиты из одной ветки в другую, это бывает полезно когда изменения сделаные другим разработчиком в его ветке, прямо сейчас нужны тебе в твоей ветке, и что бы не писать этот код заново, ты забираешь его комит себе в ветку

git rebase master - ты синхронизируешься с главной веткой в которую коммитят все разработчики проекта, это полезно когда кто-то изменил участок кода с которым ты сейчас работаешь в своей ветке, дабы через неделю ты смог без проблем смержиться с master веткой. Обычно делается каждое утро перед началом рабочего дня и в конце когда фича готова.

git merge - обычно используется когда у вас 2 и более master ветки (к примеру master и prototype) в этих ветках очень много комитов (и rebase здесь не подходит) и обчно через пару недель, maintainer репозитория наработки из prototype ветки "сливает" в master ветку по средствам этого самого git merge

P.S. Что бы легче предствить разницу между git merge и git rebase. Представь что merge как собачка на молнии у одежды - "сшивает" комиты по дате их создания.
В то время как git rebase как пожарная лестница - при применении твои коммиты крепится на конец родительской ветки

git merge используйте для мержа фич и фиксов в master ветку (как и делает это Github)
а git rebase используется для своей ветку в которой вы работаете над фичей что бы забрать последние изменения с master ветку (для этого есть очень удобная команда `git pull --rebase origin master`, аналог 3х команд (`git checkout master; git pull origin master; git checkout mybrach; git rebase master`)
Ответ написан
barker
@barker
Э… даже не знаю что тут ещё сказать можно, совершенно разные действия ведь. Грубо говоря, в первом случае ветка переставляется (со всеми коммитами), во втором отдельно взятый коммит (или несколько, схлопываются в один как вариант) патчится на другую ветку. Отсюда же и разное использование и разные ограничения. И механизм разный. Для понимания механизмов надо изучать всякие там progit и на дереве экспериментировать визуально. А если бы механизмы понимали, этого вопроса 100% не возникло бы :)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы