Ответ
Основная команда: git cherry-pick <commit-hash> — применяет изменения, внесенные указанным коммитом, к текущей ветке, создавая новый коммит.
Типичный сценарий использования: Вы хотите взять исправление бага из ветки develop и перенести его в ветку production, не сливая всю develop.
Пошаговый пример:
# 1. Находим хэш нужного коммита в истории (например, abc123)
git log --oneline develop
# 2. Переключаемся на целевую ветку
git checkout production
# 3. Применяем ("вишнёво выбираем") коммит
git cherry-pick abc123Ключевые особенности и опции:
- Создает новый коммит: Хэш нового коммита будет отличаться от исходного, хотя изменения идентичны.
- Диапазон коммитов: Можно применить несколько коммитов подряд.
git cherry-pick abc123^..def456 # Применяет все коммиты от abc123 (включительно) до def456 - Разрешение конфликтов: Если изменения конфликтуют с текущим кодом, Git остановит процесс. Нужно:
- Разрешить конфликты вручную в файлах.
- Добавить исправленные файлы:
git add <file>. - Продолжить:
git cherry-pick --continue.
- Отмена операции:
git cherry-pick --abort— полностью отменить операцию и вернуть ветку в исходное состояние.git cherry-pick --quit— прервать операцию, но оставить уже разрешенные конфликты и индекс.
Альтернативы и когда их использовать:
git merge— для интеграции всей истории ветки.git rebase— для перебазирования серии коммитов (изменяет историю).
cherry-pick идеален для точечного переноса отдельных исправлений или фич между ветками.
Ответ 18+ 🔞
А, слушай-ка, вот тебе про эту магию — git cherry-pick. Представь, что у тебя в ветке develop есть один-единственный коммит, который чинит какую-то дичь, а в production всё горит синим пламенем. И тащить всю ветку develop с её экспериментами тебе нахуй не сдалось. Вот тут-то наш вишнёвый пикер и выручает, блядь.
Что он делает, этот волшебник?
Берёт изменения из конкретного коммита (по его хэшу, этому вот abc123) и аккуратно, как хирург, накладывает их на то место, где ты сейчас стоишь (на текущую ветку). Создаётся новый коммит, изменения те же, но отпечаток (хэш) — другой. Это как скопировать кусок кода, а не перетащить его с историей болезней.
Как этим пользоваться, не обосравшись? Смотри, вот живой пример:
# 1. Сначала ищешь того самого виновника торжества в ветке develop
git log --oneline develop
# Видишь строчку: abc123 Пофиксил баг с отправкой денег на счёт мамки
# 2. Перебегаешь туда, где пожар — в ветку production
git checkout production
# 3. И говоришь гиту: "Дай-ка мне именно ЭТОТ коммит, ёпта!"
git cherry-pick abc123Всё, если звёзды сошлись и конфликтов нет, изменения применены. Новый коммит появится в production.
А если пошло по пизде и вылез конфликт? Не паникуй, такое бывает. Гит остановится и скажет: "Чувак, тут у меня волнение ебать, сам разбирайся".
- Идешь в файлы, видишь эти ебучие
<<<<<<< HEAD. Разгребаешь руками, что оставить. - Говоришь гиту: "Смотри, я всё порешал, забирай":
git add <имя_файла>. - Продолжаешь операцию:
git cherry-pick --continue.
А если передумал на середине?
git cherry-pick --abort— это полный откат, как будто ничего и не было. Ветка — девственно чиста.git cherry-pick --quit— бросил на полпути, но всякая хуйня, которую уже поправил, останется в индексе. Осторожно с этим.
Можно несколько коммитов сразу? Можно, да! Укажи диапазон.
git cherry-pick abc123^..def456Это возьмёт все коммиты, начиная с abc123 и заканчивая def456 включительно. Главное — не переборщить, а то получишь не вишнёвый пикинг, а вишнёвый ад.
Чем это лучше или хуже других команд?
git merge— это когда ты сливаешь всю ветку целиком, со всей её историей. Иногда это овердохуища лишнего.git rebase— это когда ты переписываешь историю, пересаживая целую цепочку коммитов. Мощно, но опасно, если работаешь не один.
cherry-pick — это инструмент снайпера. Точечный выстрел. Нужен один конкретный фикс из одной ветки в другую? Вот он, твой выбор. Просто помни: если ты начинаешь пикать десятки коммитов подряд, может, тебе просто merge или rebase сделать, а не извращаться? Э, бошка, думай!