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

Проблема: Когда много разработчиков в команде, то с одним объектом могут работать , вносить изменения сразу по нескольким задачам, и впоследствии, при помещении в релиз своих доработок довольно сложно вспомнить, что я изменял в модуле, на форме, какие объекты добавил в расширение и т.д.

Как автоматизировать процесс фиксирования моих изменений в конфигурацию, будь то расширение или основная конфа

при помещении писать номер заявки

(1) не про это

Git

Дальше читать много думать
https://infostart.ru/1c/articles/864097/

(1) +1. При помещении в хранилище делать максимально подробные комментарии. Что менялось, для чего, кем, в рамках какой доработки/заявки/багфикса.

(0) Для большой группы разработчиков хранилище плохо подходит.
У 1С в системе стандартов и методик описана технология разветвленной разработки. https://its.1c.ru/db/v8std/content/709/hdoc
Если используете хранилище, то лучше в том или ином виде использовать их подход.
Если кратко, то для каждой исправительной версии и для каждого технического проекта (читай - "отдельной задачи") создаётся отдельное хранилище. Только после тестирования технического проекта изменения из этих отдельных хранилищ переносятся в основное хранилище.
В сети встречается множество статей на эту тему. Но все они так или иначе в том или ином виде подразумевают разделение разработки по отдельным проектам (задачам) на отдельные конфигурации (хранилища). С последующим переносом изменений в основную конфигурацию (хранилище). В основной конфигурации (хранилище) не должно быть ситуации "с одним объектом могут работать , вносить изменения сразу по нескольким задачам".

Альтернатива такому подходу - только Git.

(0) Git

(6)+ https://v8.1c.ru/platforma/vygruzka-i-zagruzka-konfiguracii-v-fayly/

Но нужен нормальный DevOps и шустрый сервер с много места

(0) >Когда много разработчиков в команде, то с одним объектом могут работать, вносить изменения сразу по нескольким задачам

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

(0) довольно таки интересная проблема...
штатных механизмов нет, как вариант можно опубликовать хранилище на http-сервере, на нем уже самопально перехватывать данные кто что захватывает и писать их в свою БД, там уже запрашивать организационно зачем захватил
либо лапками самим вести такую информацию, придерживаясь правила "Захватил объект => отразил по какой задаче захватил"
самая прэлэсть возникает, когда тебе же дают вторую задачу по объекту, который у тебя же захвачен по первой задаче...