Pull to refresh
4
0
Печёнкин Никита @npechenkin

разработчик

Send message
Я решил, а почему бы не быть переходной стадии? Да, микросхемы…

А почему переходной стадией не стала аналоговая электроника? Помню в детстве не было предела радости, когда самодельный УКВ-ЧМ приемник «заговорил» чем-то не похожим на белый шум.
Как вы в этой схеме с бранчами работаете, кстати? Или у вас только мастер?

Нет, не только мастер, а еще develop плюс по три релизные ветви на каждую редакцию продукта и переменное число ветвей для hotfix-ов и фич. Предыдущая публикация как раз была этому посвящена. Если коротко, то используется модифицированная под наши реалии и подмодули «удачная модель ветвления»

Кстати, заглавная иллюстрация в предыдущей статье отображает реальную ситуацию в проекте по ветвям модулей, хотя, признаюсь, я выбрал самый «зрелищный» момент из всех возможных.
gitmodules и gitignore в пару мегабайт каждый

Вы преувеличиваете — «в пару мегабайт» в UTF-8 вмещается первый том «Войны и мира». С gitmodules и gitignore все скромнее выходит: упомянутые 102 модуля занимают ~10,4 кб в gitmodules и 1 (один) байт в gitignore. gitignore в нашем случае такой из-за того, что модуль-контейнер не содержит ничего кроме описателя. Приведенные размеры файлов, естественно, зависят от структуры желаемой рабочей копии.

В любом случае, в процессе разработки git-овский индекс куда как быстрее прирастает, чем эти файлы.
Ну то есть у вас под каждую версию по сути свой мастер, в который мы добавляете изменения, как я понял, патчами.


В нашей ситуации все-таки релизные ветви не совсем можно назвать мастером, поскольку подавляющее большинство 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) эти правки не нужны.
Прошу прощения, немного промахнулся с ответом — он в моем комментарии ниже.
Каждая релизная ветвь порождается от 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-а и прижилась.
Вопрос — кто принимает решение о переключении на новую версию подмодуля или на новую ветку подмодуля?

В зависимости от ситуации: если мы находимся в главном модуле-контейнере, то если переходим на develop/master или релизную ветвь linflow обойдет все зарегистрированные подмодули и предпримет попытку переключить и их на одноименную ветвь. Если переключение идет на feature или hotfix, то обхода не будет. Это поведение по умолчанию, но оно может быть изменено при необходимости переданными ключами.

но периодически вознимает проблема, что несколько человек передвигают указатели на подмодули

В нашей практике это случалось довольно часто, поскольку модулей около сотни и над ними работают несколько десятков человек. Дополнительные проблемы были еще с тем, что главный модуль содержит состояние подмодуля ссылаясь на коммит, а не на ветвь. Возможно это и логично, но куда как удобнее, когда главный модуль указывает на ветвь, которая может «жить своей жизнью» без необходимости коммитов в родительский репозиторий своих новых публичных состояний.
… преимущество перед классической схемой

linmodules обеспечивает возможность работать с каждым модулем независимо, обеспечивая при этом массовую обработку (переключение, update, pull/push и т.п.) при необходимости. Но самое важное для нашего случая — возможность просто извлекать и оперировать частью большого репозитория, так, например, для работы над ядром ЛИНТЕР-а можно извлечь ~10 подмодулей а не тащить весь репозиторий из 100+ подмодулей.
2

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity