Т.е. перед каждой задачей заново загружать себе исходники например develop если новая ветка стартует от него? Забыл упомянуть что речь про классическую разработку с использованием конфигуратора.

Коллеги, добрый день! При тестировании конфы с данными,  используем snapshot sql (моментальный снимок), после тестирования делаем rollback (возврат к снимку), иногда после такого роллбэка, все константы становятся неопределенно , а не булево , кто нибудь сталкивался с подобным?

Кластер 1С-то перезапускать полностью надо после каждого восстановления

Всем привет! Никто не сталкивался со следующей проблемой?
Есть обмен между базами по правилам. Одна база данные принимает, записывает, но не увеличивает номер принятого. Как такое может быть?

Ну это же не какой-то магией делается, а сугубо прикладным кодом конфигурации приемника

Механизм БСПшный

конечно.
если нужно переключиться на работу с другой функциональностью,
то переключаемся на ветку девелоп, git pull для нее
создаем новую ветку
и загружаем исходники в свою ИБ, обновляем свою ИБ в режиме Предприятия
и начинаем разрабатывать

Ж/р ошибок не показывает при загрузке? Возможно стоит чтение порциями транзакций и часть данных зачитывается, но далее падает по какойнить ошибке типа загрузки даты со смещением.

Спасибо, Артур. И я так понимаю, что при такой схеме разработки излишняя детализация задач вредит, верно?

1 ветка на задачу никак не может быть излишней детализацией, ящитаю

нет, не вредит.
тут как обычно, не нужно делать разные задачи одновременно )
или постоянно переключаться между задачами

А если допустим под каждую задачу выделять отдельную ИБ на период разработки? Такой практики не было?

Я наверное коряво объяснил. У нас сейчас процесс построен так, что одна бизнес-задача может быть реализована с помощью трех технических задач - например, изменение структуры метаданных, доработка прав и реализация алгоритма. В рамках системы учета задач это разные задачи, их могут реализовывать разные программисты и под каждую из технических задач создается своя ветка. Вот под этим я понимаю излишнюю детализацию :)

сейчас как это делается? 3 разраба сидят в разных базах, подключенных к 1 хранилищу?

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

вот максимально быстро в девелоп - это и есть,  так сказать,  гит-way

но для этого нужно перестроить процессы, натянуть на существующие будет тяжело. если вообще возможно. сами как раз с этим же сталкиваемся

звучит так, что вам все же нужна одна ветка под все эти три задачи

Я сейчас стою на позиции зеленого девелопа :) Соответственно, при МР выполняются различные проверки, включая ручной контроль оформления кода и максимально быстро помещать код ... скажем так, не получается :)

Вот да. А как на это гит-флоу смотрит? Я пару раз делал и мне в целом понравилось :)