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

Question

[pxx]

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

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

Помогите разобраться в отличиях. Может есть какие-то специфичные примеры, на которых разница будет отчетливо заметна.

Answer 1

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

Rebase это по сути cherry-pick нескольких коммитов за раз — пакетный режим.
Вот и вся разница.

Answer 2

[Александр]

Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.

git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
(ветка devel "растворяется" в основной ветке)

git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)

git chery-pick idea - забрать коммиты из ветки idea

Comments

[Алексей Барбарош]

Александр .В PS Nkly777 я так полагаю он писал с точки зрения даты, то в этом случае он всё правильно написал.

[Carburn]

Nkly777 все правильно написал.
`git rebase devel` не скрепляет коммиты по дате создания, а перемешает коммиты текущей ветки master, созданные в ветки master после разветвления с веткой `devel` на вершину коммитов ветки `devel`.
Команда так и называется – изменить базу.

Answer 3

[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`)

Comments

[Vitegor]

В P.S. вы наверно имел ввиду, что rebase работает как собачка на молнии?)

[Nkly777]

Vitegor: мержит коммиты по дате :)

Answer 4

[barker]

Э… даже не знаю что тут ещё сказать можно, совершенно разные действия ведь. Грубо говоря, в первом случае ветка переставляется (со всеми коммитами), во втором отдельно взятый коммит (или несколько, схлопываются в один как вариант) патчится на другую ветку. Отсюда же и разное использование и разные ограничения. И механизм разный. Для понимания механизмов надо изучать всякие там progit и на дереве экспериментировать визуально. А если бы механизмы понимали, этого вопроса 100% не возникло бы :)

Comments

[barker]

Ну по замыслу похожи, тут правы, конечно. Обе переносят «отсюда туда» :)

[jcmvbkbc]

А по-моему действие абсолютно одинаковое.
Вы никогда не пробовали в список который выкидывает git rebase -i дописать pick для произвольных коммитов?

Однако небольшая разница есть именно в пакетной обработке: при конфликте git rebase можно продолжить опцией --continue или откатить --abort. cherry-pick вроде такой возможности не имеет.

[jcmvbkbc]

Ещё одно отличие: патчи присутствующие в апстрим-бранче (достаточно совпадения содержимого, описание коммита может отличаться) будут выкинуты из перебазированной ветки. Т.е. если в ветке topic есть патчи принятые в master, то после git rebase master topic эти патчи из хвоста master...topic исчезнут. Если же сделать cherry-pick пачки коммитов в ветку, содержащую копии некоторых из них, cherry-pick будет плеваться примерно так:

nothing to commit (working directory clean)
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

Otherwise, please use 'git reset'

[Никита Лапков]

pcottle.github.io/learnGitBranching Вот это вам может помочь. Помимо изучения бранчей, там можно составлять деревья самостоятельно и все это наглядно.