Comments 9
Скажите, для проектов какого размера действует ваша рекомендация? Насколько я знаю, в openstack'е, например (в котором >10k user faced изменений на версию — и мы не про коммиты, мы про release notes), там вот, в openstack'е как раз очень приветствуют cherry-pick, потому что он приносит в бранч только то, что нужно, и ничего лишнего.
Мне кажется, автор изначально описал модель, в которой не нужны черри-пики. Если есть feature-бранчи, то и работу надо вести в feature-бранчах, а не в мастере, и потом черри-пикать. Соответственно фиксы делать в релизных бранчах и подмердживать их в мастер, а оттуда уже в фича-бранчи. Получается классический git flow.
На предыдущем месте работы использовалась несколько другая модель, в которую черри-пики хорошо укладывались. Вся разработка шла в мастере, от которого отводились релизные бранчи. Релизные бранчи нельзя было вливать обратно в мастер — существовал апстрим-проект, из которого периодически подмердживалось очень много изменений как в мастер (из мастера апстрима), так и в релизные бранчи (из релизных веток апстрима). Мерджить релизные бранчи в мастер в такой ситуации не представлялось возможным — это провоцировало огромное количество проблем на пустом месте. Поэтому все фиксы делались в мастере, и если фикс нужен был также в релизной ветке, то он черри-пикался туда из мастера. В этой модели без черри-пиков было не обойтись. При этом они отлично решали проблему и не создавали конфликтов на пустом месте — ведь мастер и релизная ветки никогда не сливались. Иногда, правда, всплывали спецэффекты из-за того что черри-пики накладывались на релизную ветку не в том же порядке, в котором они накладывались на мастер, но это было достаточно редкой ситуацией.
На предыдущем месте работы использовалась несколько другая модель, в которую черри-пики хорошо укладывались. Вся разработка шла в мастере, от которого отводились релизные бранчи. Релизные бранчи нельзя было вливать обратно в мастер — существовал апстрим-проект, из которого периодически подмердживалось очень много изменений как в мастер (из мастера апстрима), так и в релизные бранчи (из релизных веток апстрима).у нас сейчас используется именно такая же модель. Но поддерживать по 5-10 веток в 4 продуктах довольно таки хлопотно. А автоматизировать бекпортирование я так понимаю нельзя от слова совсем
Меня на неделе ругали за излишнюю умозрительность в статье: была ссылка на репозиторий и uml диаграмма, но не было фрагментов кода. Как же они были правы, как же я был не прав...
Здесь смотрю на иллюстрации и описания, и никак картина не складывается. Возьмём иллюстрацию "здесь будет конфликт". Хоть убей, не вижу, почему при черри-пике строка cherry поменяется на berry. Если в мастере она не менялась от общего предка до м2, она не перезапишется. Если менялась, словим конфликт ещё на черри-пике.
А реального примера репозитория, подтверждающего диаграмму, я не увидел. Вот и остался в недоумении и сомнении.
Ох, меня таки сбили с понталыку стрелки, которые направлены против таймлайна (от следствия к причине). На направление их справа налево внимания не обратил (направление — фигня, мне всё равно, могу читать вверх ногами, могу через зеркало), "бабах справа" не понял и "отфильтровал", на нумерацию коммитов внимания не обратил (вот же она, последовательность, стрелками указана… ОЙ). Теперь-то да, всё вдруг стало понятно.
Третья картинка в оригинале была такой:
Хватит копировать, пора сливаться. Часть 1. Конфликт слияний