@romicohen
WebDev

Постоянно приходится черри-пикать фиксы в master, а я помню, что это вроде потом вызывает проблемы при мерже из develop — как быть?

Ситуация такая, например я пикаю комиты 22abc и 33cde в master, потом пикаю или мержу их и в develop, а потом (вроде бы, точно не помню) при мерже develop в master — Git начнет ругаться, дескать такие комиты уже есть, только на другом месте.

Я правильно помню? И если да - как обойти?

Я вроде помню что можно пикать комиты, но только не как комиты, а как изменения в рабочий каталог, и потом их просто комитить и все. Это поможет? Если да — что там за команда, я реально не помню уже -)
  • Вопрос задан
  • 182 просмотра
Решения вопроса 1
sergey-kuznetsov
@sergey-kuznetsov Куратор тега Git
Автоматизатор
можно пикать комиты, но только не как комиты, а как изменения в рабочий каталог, и потом их просто комитить и все

Неважно, сразу коммит создаётся или вы его потом руками сделаете — результат получится идентичный. Если не понимаете, к чему могут привести черри-пики, то не используйте их.

Почитайте пару статей про это из цикла Хватит копировать, пора сливаться:
Часть 1. Конфликт слияний
Часть 2. Конфликт слияний, который так и не произошёл (а должен был)
Третью часть почему-то так и не перевели, но там описано как избежать проблем.
Part 3: Avoiding problems by creating a new merge base
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@fregate
Пишу, думаю
Потому что надо сначала из фича-ветки мержить в девелоп, а потом уже в мастер.

Более того, если есть релизы, то становится еще бодрее. Например, захотели сделать фикс в одном из релизов и цепочка будет выглядеть как:
releaseM, release(M+1)... release(N), develop, master
Зачастую все эти перекидывания делаются не руками, конечно, а на CI раз в день, и если не смогли роботы это все сделать, то отправляется на фикс кому-то из разработчиков, для ручного разрешения конфликтов.
Ответ написан
Комментировать
Проблема с черри-пиками в том, что они теряют историю изменений,
вот характерный пример:
при разработке фичи разработчик натолкнулся на дефект и исправил его коммитами 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.
Это проблема, так как никаких сообщений о конфликте получено не было.
sgtdptxownp7ruhucxqe84df6k4.jpeg

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы