Зачем нужен git cherry-pick?

git cherry-pick: назначение и практические применения

git cherry-pick позволяет применить конкретный коммит из одной ветки в другую БЕЗ необходимости мержить всю ветку. Это мощный инструмент для управления коммитами в комплексных workflow.

Основной синтаксис

# Применить коммит abc123 в текущую ветку
git cherry-pick abc123

# Применить несколько коммитов
git cherry-pick abc123 def456

# Применить диапазон коммитов (abc123 включительно, но def456 НЕ включая)
git cherry-pick abc123..def456

# Применить диапазон (оба включительно)
git cherry-pick abc123^..def456

Практический пример 1: Экстренный hotfix

Проблема: критический баг в production (main ветка), но main уже впереди dev на несколько коммитов.

main:    [A] -- [B] -- [C:bug] -- [D] -- [E]
                        ^
dev:     [A] -- [B] -- [X:newfeature] -- [Y]
                ^
                 Базовая точка отделения

Решение: cherry-pick баг-фикса [C] в main, потом в dev

# Находимся на main
git log --oneline main | head -5
# Output: E D C B A

# Находимся на dev
git checkout dev
git cherry-pick C

# Результат в dev
dev:     [A] -- [B] -- [X:newfeature] -- [Y] -- [C:bug-fix]

Практический пример 2: Selectively выбирать коммиты

Ваша feature ветка содержит несколько коммитов, но в main нужны только некоторые:

git checkout feature/payment
git log --oneline
# Output:
# e5f2a1c Fix: handle zero amount
# d3c4b8a Refactor: payment service
# c2b1a9f Feature: new payment method
# 8a7f6e5 Fix: database connection
# 7e6d5c4 Initial commit

# В main нужны только новый метод платежа и два фикса
git checkout main
git cherry-pick c2b1a9f  # Feature
git cherry-pick d3c4b8a  # Refactor (если нужен)
git cherry-pick e5f2a1c  # Fix zero amount

Практический пример 3: Backport в старую версию

У вас есть версии: main (v2.0) и hotfix/v1.9 (старая production)

main (v2.0):       [1.0] -- [2.0:refactor] -- [2.1:newapi]

hotfix/v1.9:       [1.0] -- [1.8:oldfeature]
                    |
                    Нужен security patch из main

# На main есть security patch
git log --oneline main | grep -i security
# Output: abc123d Security: fix SQL injection

# Переходим на старую ветку и берём patch
git checkout hotfix/v1.9
git cherry-pick abc123d

# Результат
hotfix/v1.9:       [1.0] -- [1.8:oldfeature] -- [abc123d:Security patch]

Когда использовать cherry-pick

ХОРОШО использовать cherry-pick когда:

1. Экстренные hotfixes — срочный баг в production

git checkout main
git cherry-pick hotfix/critical-bug  # Быстро в production

1. Selective commits — нужны только некоторые коммиты из feature

git cherry-pick feature/payment~3  # Берём старый коммит
git cherry-pick feature/payment~2

1. Backporting — применить фикс в несколько веток

git cherry-pick security-fix  # В main
git checkout v1.9
git cherry-pick security-fix  # В старую версию

1. Отменённые коммиты — восстановить реверт

git log --oneline | grep Revert
# Находим что-то вроде: "Revert: bad feature"
git cherry-pick <original-commit>  # Восстанавливаем

ПЛОХО использовать cherry-pick когда:

1. Как замена merge — используй merge для полной ветки

# Плохо: cherry-picking всех коммитов feature
for commit in feature~10..feature; do
    git cherry-pick $commit
done

# Хорошо:
git merge feature

1. Изменение истории main — нарушает коллаборацию

# Плохо если main уже pushed
git cherry-pick experimental
git push -f  # НИКОГДА не делай force push на shared ветки!

Обработка конфликтов

# Начинаем cherry-pick
git cherry-pick abc123
# Есть конфликты

# Решаем конфликты (edit файлы)
vim src/Payment.java

# Добавляем решение
git add src/Payment.java

# Продолжаем
git cherry-pick --continue

# Или отменяем
git cherry-pick --abort

Пример из реального проекта

# Команда разрабатывает v2.0 в main
# Production работает на v1.9 в ветке release/1.9

# В v2.0 обнаружен security баг
git checkout main
git log --oneline | head -1
# Output: a1b2c3d Security: patch XSS vulnerability

# Нужно срочно в production (v1.9)
git checkout release/1.9
git cherry-pick a1b2c3d

# Конфликты? (версии отличаются)
# Решаем руками, коммитим
git add .
git cherry-pick --continue

# Push в release
git push origin release/1.9

# Deploy на production
# тестирование
# Готово!

Альтернативы

Вместо cherry-pick:

# 1. git rebase -i (если хочешь очистить историю)
git checkout feature
git rebase -i main
# Выбираешь только нужные коммиты

# 2. git patch (если нужен файл)
git show abc123 > fix.patch
git apply fix.patch

# 3. git merge (если нужна вся ветка)
git merge feature

Ошибки при использовании

# ОШИБКА 1: empty commit
git cherry-pick abc123
# Error: The commit is empty
# Решение: --allow-empty флаг
git cherry-pick abc123 --allow-empty

# ОШИБКА 2: уже применён коммит
git cherry-pick abc123
# Error: commit already exists
# Решение: check git log перед cherry-pick

# ОШИБКА 3: конфликты которые нельзя разрешить
git cherry-pick abc123
# Conflicts
# Решение: abort и merge вместо cherry-pick
git cherry-pick --abort
git merge feature

Best Practices

# 1. Всегда проверь что берёшь
git log abc123..HEAD  # Что между коммитом и текущей веткой

# 2. Cherry-pick в порядке (старые → новые)
git cherry-pick old-commit new-commit

# 3. Никогда не cherry-pick на shared ветки (main)
# Используй merge pull request вместо

# 4. Документируй почему cherry-pick
# В PR message: "cherry-picked from main:abc123 due to"

# 5. Не делай force push после cherry-pick
git push origin feature  # Обычный push

Итог

git cherry-pick — это инструмент для:

• Экстренных hotfixes в production
• Selectively применения коммитов
• Backporting в старые версии
• Восстановления отменённых коммитов

НО используй с осторожностью, так как может запутать историю. Всегда предпочитай merge для основных веток и cherry-pick только когда действительно нужна селективность.