Что делает Git Cherry Pick и когда его следует использовать?
git cherry-pick – простой, но мощный инструмент, позволяющий выборочно переносить коммиты из одной ветки в другую. Вы можете использовать его, когда не хотите объединять всю ветку с мастером, но все же хотите включить изменения из функциональной ветки.
Что такое Git Cherry Pick и как он работает?
В Git коммиты — это единицы, которые отслеживают изменения с течением времени. Каждая фиксация может представлять собой исправление ошибки, новую функцию или часть более крупного решения. Вы можете думать о коммитах, хранящихся как связанный список, указывающий назад во времени; всякий раз, когда вы меняете HEAD ветки, Git восстанавливает файлы вашего локального каталога, принимая во внимание все коммиты, возвращающиеся к началу.
Это, конечно, упрощение, и технически Git не хранит коммиты в виде простых списков изменений, он использует BLOB-объекты на основе файлов, но принцип тот же.
Все становится сложнее, когда в дело вступают филиалы. Часто работа над фичей занимает много дней или недель. Вместо того, чтобы загромождать основной репозиторий, он помещается в отдельную ветку функций, а затем код проверяется и снова объединяется. Слияние — это, по сути, разветвление этой истории коммитов, так что вся ветка функций включается, когда Git делает свое дело.
Однако что, если вы хотите объединить некоторые вещи, но пока не хотите включать всю ветку? В этом случае вы не можете использовать git merge .
Вот где git cherry-pick становится полезным. Он делает то, что следует из названия — берет один коммит из функциональной ветки, выбирает его по отдельности и применяет к основной ветке или наоборот. Это копирует коммит, так что в целевой ветке появляется совершенно новый коммит.
Обратите внимание, что нет реальной «линии», соединяющей новый коммит в ветке master со старым коммитом. Новый выбранный коммит, созданный на мастере, вообще не ссылается на исходный коммит, коммит просто копируется. Git позаботится об этом, когда вы объедините ветки вместе, потому что коммиты рассматриваются как копии друг друга.
По сути, фиксация «переносится» в новую ветку, хотя вы должны помнить, что старая фиксация по-прежнему применяется к функциональной ветке. Однако вам не стоит отменять исходный коммит, так как это вызовет проблемы при последующем слиянии.
Почему Черри Пик?
Для этого есть несколько вариантов использования. Возможно, вы работаете над функцией, и она еще не готова к выпуску, но вы исправили ошибку в ветке функции, которую хотели бы включить в версию еженедельного выпуска. Вы можете использовать Cherry-Pick, чтобы скопировать исправление ошибки в Master, чтобы развернуть его раньше.
Или, возможно, у вас есть несколько веток для производства и разработки, и вы хотите скопировать срочное исправление ошибки из производства в разработку. Cherry Pick может сделать это тоже.
Или, возможно, вы даже случайно сделали коммит не в ту ветку. Вы можете использовать git cherry-pick , чтобы скопировать его в нужное, а затем git reset , чтобы отменить этот коммит (при условии, что он находится в HEAD ветки).
Использование Git Cherry Pick
Как только вы поймете, что делаете, git cherry-pick станет довольно простым в использовании.
Самый простой способ просмотреть историю коммитов Git в командной строке — это следующая команда, которая показывает все коммиты, но с историей ветвления и слияния, что очень важно для использования вишневого выбора:
git log --pretty=format:"%h %s" --graph
Затем вы можете просто скопировать хэш SHA1 коммита и запустить выбор вишни:
git cherry-pick 1da76d3
Обратите внимание, что вы также можете выбрать несколько коммитов одновременно, просто передав несколько хэшей.
У git cherry-pick есть несколько полезных опций:
- —no-commit применяет изменения только к вашему каталогу. Вам нужно будет подготовить и зафиксировать вручную.
- —edit позволит вам изменить сообщение фиксации.
- -x добавит сообщение «Вишенка выбрана из коммита:…»
Конечно, если вы используете клиент Git с графическим интерфейсом, такой как Fork или GitKraken, который мы настоятельно рекомендуем, вы можете просто щелкнуть правой кнопкой мыши коммит и выбрать его:
Все права защищены. © Linux-Console.net • 2019-2023
Что значит Cherry Picking в тестировании
Cherry Picking — сбор вишенок — это процесс выбора из реализованных фич тех, которые пойдут в ближайший релиз.
Когда это происходит: в том случае, если разработчам удалось создать большое количество новых фич, но менеджмент считает, что не стоит выкатывать сразу все.
Почему бы не выложить сразу все фичи:
- Усложнится поиск багов — больше новых фич значит сложее разобраться
- Может затянуться процесс тестирования — просто за счёт объёма
- Может не хватить фич на следующий релиз — например настаёт период отпусков и PM знает, что за следующий спринт будет сделано намного меньше
git cherry-pick
В git существует команда
Прочитать спецификацию можно здесь
git cherry-pick-это мощная команда, которая позволяет выбирать произвольные коммиты Git по ссылке и добавлять их к текущей рабочей головке.
Простыми словаими: cherry-pick копирует определёные коммиты из одной ветки в другую. То есть вместо полного мерджа ветки в мастер, можно добавить только некоторые коммиты
Коммит который скопирован не удаляется из оригинальной ветки — в этом состоит различие со сбором настоящей вишни, которая, конечно, не остаётся на ветке.
git cherry-pick может быть полезен для отмены изменений.
Например, предположим, что коммит случайно сделан не в ту ветвь.
Вы можете переключиться на правильную ветвь и сделать туда черри-пик.
Если сделать черри пик и потом смерджить ветку из которой он был сделать — появится дубль черрипикнутого коммита.
Это может внести путаницу, если не все в курсе происходящего.
Когда использовать git cherry pick
git cherry-pick-полезный инструмент, но не всегда лучшая практика.
Сбор вишни может привести к дублированию коммитов, и во многих сценариях, где сбор вишни будет работать, вместо этого предпочтительны традиционные слияния (merge).
С учетом сказанного git cherry-pick-это удобный инструмент для нескольких сценариев.
Командное сотрудничество
Часто команда находит отдельных членов, работающих в одном и том же коде или вокруг него.
Возможно, новая функция продукта имеет бэкэнд и фронтенд-компонент.
Возможно, существует некоторый общий код между двумя секторами продукта.
Возможно, бэкэнд-разработчик создает структуру данных, которую также должен будет использовать фронтэнд.
Фронтенд-разработчик может использовать git cherry-pick для выбора коммита, в котором была создана эта гипотетическая структура данных.
Этот выбор позволит разработчику frontend продолжить работу над своей частью проекта.
Исправления ошибок
При обнаружении ошибки важно как можно быстрее доставить исправление конечным пользователям.
Например,предположим, что разработчик начал работу над новой функцией.
Во время разработки этой новой функции они выявляют уже существующую ошибку.
Разработчик делает коммит с исправлением этой ошибки.
Этот новый коммит с патчем может быть добавлен непосредственно в мастер, чтобы исправить ошибку, прежде чем она повлияет на большее количество пользователей.
Также может возникнуть ситуация когда ошибку нашли в более поздней версии продукта, а добавить фикс нужно в несколько предыдущих версий, которые ещё не вышли из употребления.
Отмена изменений и использование коммитов из уже неактивных веток
Иногда ветвь функции может устареть и не слиться с мастером.
Иногда запрос на вытягивание может быть закрыт без слияния.
Git никогда не теряет эти коммиты, и с помощью таких команд, как git log и git reflog, их можно найти и вернуть к жизни.
Как использовать git cherry pick
Чтобы продемонстрировать, как использовать git cherry-pick, предположим, что у нас есть репозиторий со следующим состоянием ветви:
a — b — c — d Master \ e — f — g Feature
использование git cherry-pick является прямым и может быть выполнено следующим образом:
git cherry-pick commitSha
В этом примере commitSha -это commit reference.
Нужный коммит можно найти с помощью git log.
git log —oneline
Лог из другой ветки можно изучить с помощью
git log имя_ветки —oneline
В этом примере мы хотим черрипикнуть commit `f` в master.
Сначала мы удостоверяемся, что работаем над master.
git checkout master
Затем мы выполняем cherry-pick следующей командой:
git cherry-pick f
После выполнения наша git history будет выглядеть так:
a — b — c — d — f Master \ e — f — g Feature
Коммит f был успешно черрипикнут в главную ветвь
Примеры git cherry pick
git cherry pick также может выполнен с различными опциями:
Передача опции -edit приведет к тому, что git запросит commit message перед применением операции cherry-pick
Опция —no-commit выполнит выбор вишни, но вместо того, чтобы сделать новый commit, она переместит содержимое цели в рабочий каталог текущей ветви.
Опция —singoff из системы добавит строку ‘singoff’ подпись в конец cherry-pick коммит сообщения
В дополнение к этим полезным опциям git cherry-pick также принимает различные варианты стратегии слияния.
Подробнее об этих параметрах читайте в документации git merge strategies.
Кроме того, git cherry-pick также принимает ввод опций для разрешения конфликтов слияний, включая опции: —abort —continue и —quit эти опции рассматриваются более подробно в отношении git merge и git rebase.
Резюме
cherry-pick — это мощная и удобная команда, которая невероятно полезна в нескольких сценариях. cherry-pick не должен использоваться неправильно вместо git merge или git rebase. Команда журнала Git-это обязательно поможет найти обязуется сливки.
Подпишитесь на Telegram канал @aofeed чтобы следить за выходом новых статей и обновлением старых
A3.8 Приложение C: Команды Git — Внесение исправлений
Некоторые команды в Git основываются на подходе к рассмотрению коммитов в терминах внесённых ими изменений, т. е. рассматривают историю коммитов как цепочку патчей. Ниже перечислены эти команды.
git cherry-pick
Команда git cherry-pick берёт изменения, вносимые одним коммитом, и пытается повторно применить их в виде нового коммита в текущей ветке. Эта возможность полезна в ситуации, когда нужно забрать парочку коммитов из другой ветки, а не сливать ветку целиком со всеми внесёнными в неё изменениями.
Этот процесс описан и показан в разделе Схема с перебазированием и отбором главы 5.
git rebase
git rebase — это «автоматизированный» cherry-pick . Он выполняет ту же работу, но для цепочки коммитов, тем самым как бы перенося ветку на новое место.
Мы в деталях разобрались с механизмом переноса веток в разделе Перебазирование главы 3, включая рассмотрение потенциальных проблем переноса опубликованных веток при совместной работе.
Мы использовали эту команду на практике для разбиения истории на два репозитория в разделе Замена главы 7, наряду с использованием флага —onto .
В разделе Rerere главы 7 мы рассмотрели случай возникновения конфликта во время переноса коммитов.
Также мы познакомились с интерактивным вариантом git rebase , включающемся с помощью опции -i , в разделе Изменение сообщений нескольких коммитов главы 7.
git revert
Команда git revert — полная противоположность git cherry-pick . Она создаёт новый коммит, который вносит изменения, противоположные указанному коммиту, по существу отменяя его.
Мы использовали её в разделе Отмена коммита главы 7 чтобы отменить коммит слияния (merge commit).
Git: объясните «на пальцах» разницу между rebase и cherry-pick?
С августа начал активно использовать git в рабочих и личных проектах. Началось все с тотального непонимания и ненависти, постепенно пришел к любви и восхищению.
Изучил официальный учебник, прочитал и попробовал или уже внедрил много хороших практик и, неочевидных после SVN, workflow. Чувствую себя спокойно и уверенно с гитом, но как-то до сих пор не смог осознать разницу между rebase и cherry-pick. Вроде и та и другая команды грубо говоря берут оттуда и суют сюда. Одни и те же задачи из своего повседневного рациона можно сделать как с помощью одной, так и с помощью другой. Но не дает покоя мысль, что не зря они разные и я что-то упускаю. Учебник не помогает, гугл не спасает.
Помогите разобраться в отличиях. Может есть какие-то специфичные примеры, на которых разница будет отчетливо заметна.
- Вопрос задан более трёх лет назад
- 187548 просмотров
Комментировать
Решения вопроса 1
Сергей Кузнецов @sergey-kuznetsov Куратор тега Git
Автоматизатор
Rebase это по сути cherry-pick нескольких коммитов за раз — пакетный режим.
Вот и вся разница.
Ответ написан более года назад
Комментировать
Нравится 2 Комментировать
Ответы на вопрос 3
Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.
git rebase devel — собачка на молнии — «сшивает» коммиты по дате их создания
(ветка devel «растворяется» в основной ветке)
git merge devel — пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)
git chery-pick idea — забрать коммиты из ветки idea
Ответ написан более трёх лет назад
Нравится 98 2 комментария
Алексей Барбарош @mariusraver
Александр .В PS Nkly777 я так полагаю он писал с точки зрения даты, то в этом случае он всё правильно написал.
Nkly777 все правильно написал.
`git rebase devel` не скрепляет коммиты по дате создания, а перемешает коммиты текущей ветки master, созданные в ветки master после разветвления с веткой `devel` на вершину коммитов ветки `devel`.
Команда так и называется – изменить базу.
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`)