В проде то крутит кто в итоге?

В мире 1С врядли

Не порядок. Делали же демо для этих целей.

Демо не прод

Поругайте схему пожалуйста. Разработка ведётся с использованием хранилища и гита, приоритет у хранилища, гит используется для контроля качества кода, реквестов, сборок тестовых cf по feature-веткам. Проблема в том, что разработчики постоянно хотят актуализировать код, написанный другими. С этой целью они дёргают из хранилища изменения. В результате в локальный репозиторий сыпятся не только их изменения, но и чужие, которые гит радостно индексирует. Я планирую посоветовать тащить параллельно изменения из удалённого репозитория и делать ребейз еще неопубликованной ветки, над которой ведётся работа. Или есть более простые варианты?

Зачем вообще в этой схеме хранилище если вы уже нативно с гитом работаете?

По техническим причинам :)

Меня, как нуба, интересует правильное ли решение я для гита планирую применить?

правильное решение для гита - юзать только гит, без хранилищ

все остальное костыли

> В результате в локальный репозиторий сыпятся не только их изменения, но и чужие, которые гит радостно индексирует.

раскройте тезис

правда юзать только гит в 1С без костылей тоже не получится

Ждём Снегопат?

нет

Два разработчика. Один решает одну задачу, другой - другую. Первый решил задачу, прошли этапы тестирования, решение попало в dev и в хранилище. Возможно даже обновился prod. Второй видит это и забирает из хранилища изменения по этой задаче. При этом в локальном репозитории этих изменений у него нет. Соответственно, когда он решит задачу и будет выгружать конфигурацию в исходники чтобы обновить и опубликовать свою ветку он столкнётся с тем, что выгрузятся не только его изменения, но и изменения по первой задаче.

пускай разработчик разделяет этап синхронизации с хранилищем и выгрузку своих изменений.

или же вообще забирает конфигурацию из гита, а не хранилища

Раскройте тезис :)

Нет. Конфигурация берётся из хранилища. В гит изменения выгружаются в одну сторону, затем архитектор собирает их через реквесты и помещает в хранилище

у вас недоразветвленная разработка. часть информации о ветках и их синхронизации - эфемерная, и не попадает под систему контроля версий. логично, что когда разработчик возвращается в систему контроля версий, эта информация в нее попадает. т.е. это не проблема как таковая.