git cherry-pick бере зміни з указаного коміту й застосовує їх як новий коміт у поточній гілці.
git switch release/2.4
git cherry-pick a1b2c3d
Новий коміт має той самий diff і повідомлення, але інший хеш: в нього інший батько й час створення.
Типові сценарії:
- виправлення в реліз: баг виправлено в
main, і те саме виправлення потрібне в гілці підтримуваної версії; - коміт не в тій гілці: зроблено коміт у
mainзамість гілки задачі - перенести його в потрібну гілку, а зmainприбрати; - врятувати частину роботи з гілки, яку не будуть зливати.
Кілька комітів:
git cherry-pick a1b2c3d e4f5g6h # окремі коміти
git cherry-pick main~3..main # діапазон (без main~3)
Корисні параметри:
| Параметр | Що робить |
|---|---|
-x |
додає в повідомлення рядок (cherry picked from commit ...) - видно походження |
--no-commit (-n) |
застосувати зміни без коміту, щоб об'єднати кілька в один |
--continue / --abort |
продовжити після конфлікту чи скасувати |
Конфлікти розв'язуються як при злитті: виправити файли, git add, git cherry-pick --continue.
Чому не варто зловживати:
- дублікати в історії: той самий зміст у двох комітах з різними хешами. Коли гілки згодом зіллються, Git зазвичай розпізнає однакові зміни, але інколи це дає конфлікти;
- заміна злиттю: якщо доводиться переносити десятки комітів, правильніше злити гілку чи переглянути процес роботи з гілками.
Порада: для виправлень у кількох версіях використовуйте -x - тоді з історії релізної гілки видно, звідки прийшла кожна зміна.
