Что такое git cherry-pick и для чего он используется
Что проверяют
Понимаете ли вы, что команда копирует коммит, а не переносит, и знаете ли, когда её применение оправдано.
Как отвечать
git cherry-pick <хеш> применяет изменения указанного коммита к текущей ветке, создавая новый коммит с другим идентификатором. Исходный остаётся на месте.
Типичные случаи:
- срочное исправление в релизную ветку: починили в main, а в релиз нужно только это одно изменение, без остального;
- коммит попал не в ту ветку: копируем в нужную, из неверной убираем;
- перенос отдельной правки из ветки, которую целиком вливать рано.
Полезные флаги: диапазон A..B, -n чтобы применить без коммита и собрать несколько изменений в одно, -x чтобы в сообщение добавилась ссылка на исходный коммит (полезно для релизных веток), --continue и --abort при конфликтах.
Главный недостаток, о котором стоит сказать: дублирование. Один и тот же по смыслу набор изменений существует в двух коммитах с разными идентификаторами. При последующем слиянии веток git может не понять, что это одно и то же, и выдать конфликт. Поэтому cherry-pick это точечный инструмент, а не способ регулярно синхронизировать ветки: для этого есть merge и rebase.
Где спотыкаются
Считают, что команда переносит коммит, а не копирует.
Используют её вместо слияния и получают расходящуюся историю с дублями.
Не знают про -x и потом не могут найти, откуда взялось изменение в релизной ветке.
Копируют коммит из середины цепочки, забыв, что он зависит от предыдущих, и получают неработающий код.