Pull to refresh

Comments 9

Скажите, для проектов какого размера действует ваша рекомендация? Насколько я знаю, в openstack'е, например (в котором >10k user faced изменений на версию — и мы не про коммиты, мы про release notes), там вот, в openstack'е как раз очень приветствуют cherry-pick, потому что он приносит в бранч только то, что нужно, и ничего лишнего.

Возможно они не сливают потом ветки, в которые копируют коммиты. Вся суть статьи в том, что если смешивать эти две операции, то возникнут проблемы. Если даже целые VCS, основанные на модели патчей, это Darcs, pijul. Последний так вообще претендует на математическую корректность, основываясь на теории категорий

Да. Мастер не вливается в stable, потому что мастер бежит очень быстро, а стабильные бранчи держатся долго.

Мне кажется, автор изначально описал модель, в которой не нужны черри-пики. Если есть feature-бранчи, то и работу надо вести в feature-бранчах, а не в мастере, и потом черри-пикать. Соответственно фиксы делать в релизных бранчах и подмердживать их в мастер, а оттуда уже в фича-бранчи. Получается классический git flow.


На предыдущем месте работы использовалась несколько другая модель, в которую черри-пики хорошо укладывались. Вся разработка шла в мастере, от которого отводились релизные бранчи. Релизные бранчи нельзя было вливать обратно в мастер — существовал апстрим-проект, из которого периодически подмердживалось очень много изменений как в мастер (из мастера апстрима), так и в релизные бранчи (из релизных веток апстрима). Мерджить релизные бранчи в мастер в такой ситуации не представлялось возможным — это провоцировало огромное количество проблем на пустом месте. Поэтому все фиксы делались в мастере, и если фикс нужен был также в релизной ветке, то он черри-пикался туда из мастера. В этой модели без черри-пиков было не обойтись. При этом они отлично решали проблему и не создавали конфликтов на пустом месте — ведь мастер и релизная ветки никогда не сливались. Иногда, правда, всплывали спецэффекты из-за того что черри-пики накладывались на релизную ветку не в том же порядке, в котором они накладывались на мастер, но это было достаточно редкой ситуацией.

На предыдущем месте работы использовалась несколько другая модель, в которую черри-пики хорошо укладывались. Вся разработка шла в мастере, от которого отводились релизные бранчи. Релизные бранчи нельзя было вливать обратно в мастер — существовал апстрим-проект, из которого периодически подмердживалось очень много изменений как в мастер (из мастера апстрима), так и в релизные бранчи (из релизных веток апстрима).
у нас сейчас используется именно такая же модель. Но поддерживать по 5-10 веток в 4 продуктах довольно таки хлопотно. А автоматизировать бекпортирование я так понимаю нельзя от слова совсем

Меня на неделе ругали за излишнюю умозрительность в статье: была ссылка на репозиторий и uml диаграмма, но не было фрагментов кода. Как же они были правы, как же я был не прав...


Здесь смотрю на иллюстрации и описания, и никак картина не складывается. Возьмём иллюстрацию "здесь будет конфликт". Хоть убей, не вижу, почему при черри-пике строка cherry поменяется на berry. Если в мастере она не менялась от общего предка до м2, она не перезапишется. Если менялась, словим конфликт ещё на черри-пике.


А реального примера репозитория, подтверждающего диаграмму, я не увидел. Вот и остался в недоумении и сомнении.

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

Ох, меня таки сбили с понталыку стрелки, которые направлены против таймлайна (от следствия к причине). На направление их справа налево внимания не обратил (направление — фигня, мне всё равно, могу читать вверх ногами, могу через зеркало), "бабах справа" не понял и "отфильтровал", на нумерацию коммитов внимания не обратил (вот же она, последовательность, стрелками указана… ОЙ). Теперь-то да, всё вдруг стало понятно.

Sign up to leave a comment.

Articles