Проблема с черри-пиками в том, что они теряют историю изменений,
вот характерный пример:
при разработке фичи разработчик натолкнулся на дефект и исправил его коммитами
b1 и
b2;
изменения затронули файл
File A;
проблема проявилась в релизе и исправления срочно затянули в мастер черри-пиками
b1' и
b2';
несмотря на то, что
b1, b2 и
b1', b2' имеют одни и те же изменения кода,
для гита это совершенно отличные коммиты, которые не имеют никакой связи между собой;
разработчик, продолжая разработку фичи, обнаружил, что исправления в
b1, b2 совершенно лишние
и проблема на самом деле в файле
File B;
поэтому коммитом
b3 разработчик откатывает изменения
b1, b2 в файле
File A и вносит необходимые изменения в
File B;
после завершения разработки фичи её вливают в девелоп, куда ранее был влит мастер.
Что мы имеем в итоге в ветке девелопа? А имеем изменения одновременно в файле
File A ,
которые туда попали из коммитов
b1', b2' и изменения в файле
File B из коммита
b3.
Это проблема, так как никаких сообщений о конфликте получено не было.
Как правильно поступить в таком случае?
Собственно проблема возникла из-за того, что ветка
feature это смесь двух работ: исправления ошибки и разработки фичи.
Поэтому и решение в том, чтобы выделить ветку исправления ошибки отдельно, указав git'у на это:
создаём ветку
bugfix, куда черри-пикаем
b1 и
b2;
после этого первым же делом вливаем эту ветку в фичу, тем самым указывая git'у, что конфликт слияния в этой точке разрешён;
git о конфликте в момент слияния ничего не скажет и молча сольёт, так как файлы одинаковые, но тем не менее он там есть и именно он приводит к проблемам в предыдущем сценарии;
далее смело вливаем ветку
bugfix в мастер.
Всё, после этого проблемы с этими коммитами не будет.
При вливании фичи в девелоп git верно обнаружит для файла
File A общего предка и откатит в нём изменения в пользу файла
File B.
