Git cherry-pick: перенос отдельного коммита и проверка результата

git cherry-pick применяет изменения выбранного коммита к текущей ветке и обычно создаёт новый коммит. Команда полезна, когда в релиз нужно перенести отдельное исправление, не объединяя всю исходную ветку. Перед переносом проверьте зависимости исправления и состояние рабочей копии.

В разборе Mentoring.digital возьмём условные ветки release и feature. Имена и хеш в командах нужно заменить значениями вашего учебного репозитория.

Подготовка: что именно переносится

git status --short
git log --oneline feature -5
git show --stat COMMIT_HASH
git show COMMIT_HASH

Пустой status --short означает отсутствие показанных изменений в рабочем дереве и индексе. Если изменения есть, сначала осознанно завершите или сохраните свою работу. Не запускайте reset --hard ради подготовки: это может уничтожить нужные правки.

В diff проверьте, не использует ли исправление функцию, добавленную предыдущим коммитом feature. Успешное применение патча не доказывает, что код соберётся и выполнится в release.

Переносим исправление

git switch release
git cherry-pick COMMIT_HASH
git log -1 --oneline
git show --stat HEAD

После обычного переноса появляется новый коммит со своим родителем. Поэтому его хеш обычно отличается от исходного. Cherry-pick переносит изменение, а не делает целевую ветку копией всей истории feature.

Если коммит относится к уже опубликованной ветке и важна связь с источником, опция -x добавляет ссылку на исходный хеш в сообщение коммита. Сначала проверьте принятые в команде правила. Для merge-коммита нужен отдельный выбор основной родительской линии; этот сценарий нельзя механически подставить в пример с обычным коммитом.

Что делать при конфликте

Посмотрите git status, откройте конфликтующие файлы и выберите согласованное итоговое поведение. Удалить маркеры конфликта недостаточно: проверьте смысл обеих версий. После исправления:

git add path/to/file
git cherry-pick --continue

Если выбранное исправление не подходит, используйте git cherry-pick --abort. Команда возвращает состояние до начатой последовательности переноса. Применяйте её, пока операция действительно находится в процессе; проверяйте status.

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

Проверяем результат, а не только код возврата

1. Сравните итоговый diff с ожидаемым исправлением.
2. Запустите тест, который воспроизводит исходную ошибку.
3. Проверьте сборку и затронутые соседние сценарии.
4. Убедитесь, что в перенос не попали локальные настройки и секреты.
5. Зафиксируйте связь с исходной задачей в принятом процессе ревью.

Нажатие push не входит в этот учебный сценарий. Публикация ветки и выпуск исправления требуют обычной проверки проекта.

Работу с историей можно отработать на курсах Git. Сложный перенос между ветками разберите с наставником по Git.