Что такое cherry-pick в Git

Cherry-pick отвечает на задачу: взять одно конкретное изменение из другой ветки и применить его здесь. Вы не сливаете всю ветку, не переносите весь ее контекст и не делаете ветку линейной. Вы просите Git взять diff выбранного коммита и наложить его на текущую ветку.

Базовый пример:

git switch release
git cherry-pick abc123

После этого в ветке release появится новый коммит с теми же изменениями, что были в abc123. Hash будет другим, потому что у нового коммита другой родитель и другое место в истории.

Самый понятный сценарий на фронтенде: вы исправили баг в feature-ветке, но feature еще не готова к релизу. Например, в ней есть большой редизайн, а маленький fix формы нужен в production уже сегодня. Тогда cherry-pick позволяет перенести только fix, не подтягивая весь незавершенный код.

Хорошая формулировка на интервью:

Я использую cherry-pick для точечных переносов, например hotfix или backport в release-ветку. Но сначала проверяю, что коммит не зависит от других изменений, иначе можно перенести только половину решения.

Это звучит сильнее, чем просто назвать команду, потому что вы сразу показываете границы инструмента.

Cherry-pick не лучше и не хуже merge сам по себе. Это инструмент для другой задачи. Если вы хотите интегрировать всю ветку, сохранить контекст review и не потерять связанные изменения, обычно нужен merge или pull request. Если вы хотите взять один самостоятельный fix, cherry-pick может быть быстрее и чище.

Rebase тоже решает другую задачу. Он переносит цепочку коммитов на новую базу и переписывает историю этой цепочки. Cherry-pick копирует выбранные изменения в текущую ветку. На интервью полезно прямо проговорить эту разницу.

Перед командой стоит убедиться, что вы находитесь в целевой ветке. Частая практическая ошибка: разработчик cherry-pick-ит fix не туда, потом получает лишний коммит в рабочей ветке и тратит время на откат.

Плохой сценарий:

# Плохо: вы не проверили текущую ветку
git cherry-pick abc123
git push

Так можно отправить fix не в ту ветку, запустить лишний deploy или оставить release без нужного исправления. Безопаснее сначала проверить ветку, посмотреть состав коммита и прогнать минимальные проверки.

Безопаснее так:

git status
git switch release
git pull --ff-only
git show --stat abc123
git cherry-pick abc123
npm test

Набор проверок зависит от проекта. Если тестов нет, все равно проверьте хотя бы сборку или конкретный пользовательский сценарий в браузере. Для фикса формы это ввод, submit, disabled-состояние, сообщение об ошибке и повторная отправка. Для сетевого фикса это один запрос вместо лишних дублей, корректная отмена или игнорирование устаревшего ответа.

Конфликт при cherry-pick означает, что Git не смог автоматически применить изменения к текущей ветке. Это нормальная ситуация, особенно если ветки давно разошлись или один и тот же файл менялся в разных местах.

Если вы понимаете конфликт, исправьте файлы, добавьте их в индекс и продолжите операцию:

git status
# исправить файлы
git add src/Form.tsx
git cherry-pick --continue

Если конфликт слишком большой или вы поняли, что коммит зависит от других изменений, лучше отменить перенос:

git cherry-pick --abort

На интервью не стоит говорить, что вы просто удаляете конфликтные куски. Лучше сказать, что проверяете смысл изменений и выбираете между корректным продолжением и безопасным откатом.

Короткий сильный ответ должен быть таким: cherry-pick переносит не ветку, а выбранное изменение, создает новый коммит и требует проверки зависимостей. Для frontend это особенно важно, потому что ошибка может проявиться не сразу в Git, а в сборке, роутинге, UI-сценарии или интеграции с API.

Если хотите звучать уверенно, добавьте пример из рабочего процесса: hotfix в release, backport исправления или перенос маленького исправления без незавершенной feature-ветки. Затем назовите команды для конфликта: --continue и --abort.