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

Question

[Роми]

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

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

Я вроде помню что можно пикать комиты, но только не как комиты, а как изменения в рабочий каталог, и потом их просто комитить и все. Это поможет? Если да — что там за команда, я реально не помню уже -)

Comments

[mayton2019]

А как выглядит текст "ругани" git?

[Роми]

mayton2019, я уже не помню, но помню что был трабл с этим, мне этот комит пришлось сквошить с другими (это было то решение которое я нашел на тот момент)

То есть, понимаешь в чем соль была - комиты были с одинаковыми хэшами, но в разных местах цепочки ))

Или черри-пик их переименовывает? Щас уточню кстати, я не уверен что тот прошлый косяк был именно изза черри-пика

[mayton2019]

Роми, воспроизведи этот баг. Это важно.

[mayton2019]

Я черри-пикнул. При слиянии с мастером получил мерж-конфликт. Нормальная ситуация ИМХО.

$ git merge feature1
Auto-merging file1.c
CONFLICT (content): Merge conflict in file1.c
Automatic merge failed; fix conflicts and then commit the result.

Не ошибка. Рабочий момент.

У вас что?

[Сергей Кузнецов]

В английском языке нет наших падежей, поэтому ваше develop-а звучит как икота ))
Не пытайтесь прицепить окончания ни через дефис, ни через апостофы — выглядит нелепо.
Хочется русских падежей — так и пишите русскими буквами, как это вы сделали с cherry-pick.

А ещё невозможна в принципе ситуация, когда два коммита имеют одинаковый хэш.
Это заложено в саму архитектуру Git.
Но может быть, что два коммита производят одинаковые модификации и это нормально.
Иногда при перебазировании может оказаться что на определенном шаге очередной pick породил пустой коммит. Это не ошибка, но гит выводит предупреждение и позволяет спокойно продолжить rebase. Может с этим вы столкнулись?

При merge подобной проблемы не бывает. Git молча создаст пустой коммит слияния и всё.

Поэтому конкретизируйте пожалуйста свой вопрос. Процитируйте точный текст «ошибки», или хотя бы выпишите какие команды вводили перед этим.

[Роми]

Хорошо, спасибо за комментарии, я как раз скоро буду мержить девелоп, непременно отпишусь по факту чего там получилось.

[Роми]

А ещё невозможна в принципе ситуация, когда два коммита имеют одинаковый хэш.
Это заложено в саму архитектуру Git.

То есть когда я пикаю комит в другую ветку - он там получает другой хэш или что?

[Сергей Кузнецов]

Роми, совершенно верно. При копировании создаётся совершенно новый коммит с другим sha-хэшем.
Хотя бы потому, что для расчета хэша используется не только состояние проекта, которое тоже изменилось, но и металанные — автор, время, предки.

Answer 1

[Сергей Кузнецов]

можно пикать комиты, но только не как комиты, а как изменения в рабочий каталог, и потом их просто комитить и все

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

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

Answer 2

[Anton F]

Потому что надо сначала из фича-ветки мержить в девелоп, а потом уже в мастер.

Более того, если есть релизы, то становится еще бодрее. Например, захотели сделать фикс в одном из релизов и цепочка будет выглядеть как:
releaseM, release(M+1)... release(N), develop, master
Зачастую все эти перекидывания делаются не руками, конечно, а на CI раз в день, и если не смогли роботы это все сделать, то отправляется на фикс кому-то из разработчиков, для ручного разрешения конфликтов.

Answer 3

[Станислав Бушуев]

Проблема с черри-пиками в том, что они теряют историю изменений,
вот характерный пример:
при разработке фичи разработчик натолкнулся на дефект и исправил его коммитами 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.

Comments

[Сергей Кузнецов]

Поправьте опечатки
при разработки → при разработке
git → Git
git'у → гиту