Comments 8
Вы написали, что linflow позволяет
Вопрос — кто принимает решение о переключении на новую версию подмодуля или на новую ветку подмодуля?
У нас похожая схема (только через классические подмодули), но периодически вознимает проблема, что несколько человек передвигают указатели на подмодули, и, соответственно, возникает конфликты. Они решаемы, но присутствует некая головная боль, из-за которой все подозревают git в глупости.
А так — весьма любопытно, но как мне показалось — слегка поверхностно про linmodules, явно из статьи не следует преимущество перед классической схемой.
согласованно переключаться на ветви и теги во всех модулях вслед за модулем-контейнером.
Вопрос — кто принимает решение о переключении на новую версию подмодуля или на новую ветку подмодуля?
У нас похожая схема (только через классические подмодули), но периодически вознимает проблема, что несколько человек передвигают указатели на подмодули, и, соответственно, возникает конфликты. Они решаемы, но присутствует некая головная боль, из-за которой все подозревают git в глупости.
А так — весьма любопытно, но как мне показалось — слегка поверхностно про linmodules, явно из статьи не следует преимущество перед классической схемой.
Вопрос — кто принимает решение о переключении на новую версию подмодуля или на новую ветку подмодуля?
В зависимости от ситуации: если мы находимся в главном модуле-контейнере, то если переходим на develop/master или релизную ветвь linflow обойдет все зарегистрированные подмодули и предпримет попытку переключить и их на одноименную ветвь. Если переключение идет на feature или hotfix, то обхода не будет. Это поведение по умолчанию, но оно может быть изменено при необходимости переданными ключами.
но периодически вознимает проблема, что несколько человек передвигают указатели на подмодули
В нашей практике это случалось довольно часто, поскольку модулей около сотни и над ними работают несколько десятков человек. Дополнительные проблемы были еще с тем, что главный модуль содержит состояние подмодуля ссылаясь на коммит, а не на ветвь. Возможно это и логично, но куда как удобнее, когда главный модуль указывает на ветвь, которая может «жить своей жизнью» без необходимости коммитов в родительский репозиторий своих новых публичных состояний.
… преимущество перед классической схемой
linmodules обеспечивает возможность работать с каждым модулем независимо, обеспечивая при этом массовую обработку (переключение, update, pull/push и т.п.) при необходимости. Но самое важное для нашего случая — возможность просто извлекать и оперировать частью большого репозитория, так, например, для работы над ядром ЛИНТЕР-а можно извлечь ~10 подмодулей а не тащить весь репозиторий из 100+ подмодулей.
Баян
Ветви релизов не могут быть закрыты пока осуществляется сопровождение продукта, так на момент написания этих строк багфиксы и часть нового функционала вносятся на все версии выпущенные с начала 2009 года.
Не понял момента с незакрываемостью веток релизов. Вы ведь когда-то делаете, собственно, релиз. Значит можно закончить ветку release/1.0.0, а в случае дополнение сделать из неё ветку release/1.0.1? А если вы не закрываете ветку – как вы помечаете факт релиза?
Каждая релизная ветвь порождается от develop, а не от предыдущей. Факт релиза отмечается тегом на ветви.
Допустим, что ваш пример (release/1.0.0 и release/1.0.1) отвечает порядку нумерации версии major.minor.maintenance, тогда репозиторий будет иметь одну релизную ветвь release/1.0 и два тега release_1.0.0 и release_1.0.1, которые указывают на соответствующие моменты выхода версий. Соответственно, следующая релизная ветвь будет необходима, только когда потребуется выпустить версию release/1.1.0
Возможно, было бы правильнее называть релизные ветви ветвями версий, но терминология досталась «по наследству» от оригинальной работы Vincent Driessen-а и прижилась.
Допустим, что ваш пример (release/1.0.0 и release/1.0.1) отвечает порядку нумерации версии major.minor.maintenance, тогда репозиторий будет иметь одну релизную ветвь release/1.0 и два тега release_1.0.0 и release_1.0.1, которые указывают на соответствующие моменты выхода версий. Соответственно, следующая релизная ветвь будет необходима, только когда потребуется выпустить версию release/1.1.0
Возможно, было бы правильнее называть релизные ветви ветвями версий, но терминология досталась «по наследству» от оригинальной работы Vincent Driessen-а и прижилась.
Ну то есть у вас под каждую версию по сути свой мастер, в который мы добавляете изменения, как я понял, патчами. И сразу же ставить тег релиза, так как, как было указано выше, в «релизных» ветках у вас код всегда готов поехать на бой. То есть это все-равно, что коммитить в мастер. Чем вам не нравится идея делать ветки следующий релизов от старых релизов (для того, чтобы не забирать изменения из мастера, а в мастер отправлять все изменения в старых релизах? Кстати, да, не совсем понятно, как изменения из релизных веток попадают в мастер. Только параллельно, патчами из фича-веток?
Ну то есть у вас под каждую версию по сути свой мастер, в который мы добавляете изменения, как я понял, патчами.
В нашей ситуации все-таки релизные ветви не совсем можно назвать мастером, поскольку подавляющее большинство hotfix-ов глобальные, т. е. затрагивают все актуальные версии, поэтому они (hotfix branches ) чаще всего заводятся от develop, вливаются в него же и потом расходятся по актуальным release branches.
Что касается переноса изменений, то разработчиков не ограничивают какими средствами это делать, но если использовать linflow, то там реализовано две стратегии: для feature — это простой merge, а для hotfix производится поиск родительской ветви и точки ветвления от нее, а затем диапазон коммитов от этой точки до HEAD переносятся cherry-pick -ом в целевую.
Чем вам не нравится идея делать ветки следующий релизов от старых релизов (для того, чтобы не забирать изменения из мастера, а в мастер отправлять все изменения в старых релизах?
Почему же не нравится, хорошая идея, единственное что смущает — потенциальное усложнение истории и структуры ветвей. Нам такой вариант не подойдет еще по специфической для проекта причине: ЛИНТЕР выпускается в четырех редакциях с разным функционалом, каждая из которых еще имеет несколько поддерживаемых релизов, соответственно как минимум 4 ветви (самые свежие версии в редакциях) регулярно получают одинаковые правки, логично, что они получают их с мастера, а не с «соседней» release baranch.
Кстати, да, не совсем понятно, как изменения из релизных веток попадают в мастер. Только параллельно, патчами из фича-веток?
Они из релизных ветвей в мастер не должны попадать: новый функционал (feature ветви) создаются только от develop(master) и, если и переносятся на уже вышедший релиз, то release branch в этом случае — репициент. Аналогичная ситуация с упомянутыми выше «глобальными» исправлениями — они тоже создаются от develop(master). В тех же случаях, когда hotfix затрагивает только одну версию/релиз, то ветвь заводится от release, в нее же вливается, а на develop(master) эти правки не нужны.
Sign up to leave a comment.
Модель ветвления и управления модулями git для большого проекта