Так. В мою защиту. А разве подтверждённый МР не может являться тем самым коммитом ?

https://t.me/ssl1c/68690
Вот так будет.
Я сам на это натыкался

если разрабам для выполнения своей задачи надо забирать код из еще не влитого мерж-реквеста, то это скорее косяк в организации разработки и разделения/очередности задач

Причем у этой фичи борода с начала УФ

исключение - если разраб уже работает поверх фича-бранча, а не девелопа. то есть его фича-бранч ветвится от другого фича-бранча. но тут просто "девелопом" становится другой бранч :)

скорее, это косяк, который надо регистрировать.

что НайтиСтроки при актуальном кэше на клиенте не лезет на сервер? пожалуйста, не фиксите этот баг! :D

ты читал СП? https://t.me/ssl1c/68747

тут косяк точно есть, вопрос - где

читал, да. потому и говорю

надеюсь, что в СП :)

Нет. Формально комитеты идут в порядке очередности, но в фича-ветке с кодом нет требуемых изменений по структуре например, те она не самодостаточна. Это организационная проблема, но отражается на Cicero

с другой стороны я могу понять 1С, которая не хочет в СП описывать в каких случаях метод не вызовет сервер. поэтому просто превентивно ругает

Косяк в СП - удивил

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

Да, это один из вариантов. Хорошо, спасибо большое за советы

если кратко,
то должно быть несколько контуров, со своими ограничениями.
1. контур разработки, разрабы должны сидеть на отдельном серваке/кластере, чтобы своими "погаными" запросами в консоли не ложить продуктивный сервер.
 рядовые разрабы, если это не ларек, не должны иметь доступ к продуктивным данным, и данные в разработческих базах должны обезличиваться, чтобы снизить риск утечек коммерческой инфы
 плюс на сервере разработки включена серверная отладка и есть всякие хранилища, гиты, анализаторы качества кода, сборщики/разборщики и т.д. и т.п. Вся эта фигня не нужна в продуктиве.
2. контур тестирования/стейджинга. Могут быть отдельные, могут быть и объединены. Там ответственные люди тестирую фичи, и выносят вердикт о допуске релиза на прод. Тестовый контур так же может быть и без чувствительных данных в базе. Лишь бы они были условно похожи на те что в боевой.
Стейджинг это почти полная копия продуктивного окружения и данных, там проверяется, что релиз на боевую базу накатывается как надо, и может быть делаются какие-то особые проверки, нагрузочное тестирование и т.д., проверка развертывания релиза, например разрабы создали файл поставки, поставка накатывается на базу и работают обработчики обновления, миграции данных всякие т.д.
3. боевая база, ну тут все понятно

это все нужно для разделения ответственности и обеспечения качества. Процесс прохождения кода по этим этапам условно можно назвать CI/CD, он может быть и самый простой, когда мы переносим везде изменения через cf и сравнение/объединение, проверяем код глазами, и тестируем руками, а может быть и крутой, здесь собсно сокрыт большой потенциал для автоматизации (автотесты, автопроверки кода, скрипты развертывания и настройки инфраструктуры, это можно хоть башем, хоть питоном, хоть оскриптом).
так же стейджинговый контур должен как можно лучше повторять характеристики продуктивного контура, и желательно, каждый раз разворачиваться заново, например накатываться новая виртуалка, база разворачиваться из последнего бекапа, и т.д. и т.п, чтобы проверить все компоненты системы на случай сбоя и необходимости восстановления.

блин...получилась простыня

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

Называть отладку "не нужной в продуктиве фигней" - это сильно