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

с другой стороны в конфигураторе мержа форм нет, так что жрать кактус и плакать

Ну избыточно сработавший конфликт - это не так страшно, как молчаливо пропущенный.
Первый хоть увидеть и разрулить можно.

форма, после автомержа гита, если случайно не развалилась, но поплыла по идентификаторам - эт такая веселая штука, в которой обработчики все рандомно привязаны к разным элементам формы )))

В прекоммите есть сценарий автогенерации id элементов форм, который самостоятельно это все разруливает. Так что это не проблема от слова совсем

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

эт тип ручками написать скриптец который будет генерить id-ки? а оно это единообразно делает? потом не надо будет при подтягивании изменений из мастера - разруливать конфликты в id каждый раз? история изменений от этих автогенераций мусорится не будет?

это функционал едт берется? или какой то свой кастомный?

с шансом потом огрести проблем, если едт изменит алгоритмы навешивания id

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

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

● тексты модулей сравниваются по именам процедур;

● элементы формы сравниваются по типу элемента и его имени;

● параметры формы сравниваются по имени;

● команды сравниваются по имени;

● реквизиты сравниваются по именам;

● для командного интерфейса сравнение выполняется по виду команды (автоматическая или реализованная разработчиком) и имени команды.

Совпадающие элементы (по именам) в основной форме будут заменены (заменяются свойства, размеры и расположение), если выбран приоритет загружаемой конфигурации, и оставлены без изменения, если выбран приоритет основной формы. Также могут быть объединены некоторые свойства элементов формы, например, список выбора, заголовки на разных языках и т. д.

Режим объединения формы можно задавать как в целом для всей формы (сама форма и модуль формы) ‑ для обычной и управляемой формы, так и отдельно для формы и ее модуля

и как бы нахрена велосипед свой изобретать, если это работа едт?

Айдишники важны только в рамках самой xml, цифра ни на что не влияет по большому счету, нужно просто чтоб оно было уникальное

это если ты один эту форму лопатишь - да, а если у тя 50+ разрабов, с кучей своих веток?

Ну речь же шла про мердж руками, например если не работать в едт.
С едт велосипед не нужен

которым каждый раз прилетает расколбас по айдишкам

Какая разница? После комитета все эелемнты форм выравниваются

Нет расколбаса, они линейные

в варианте без едт, имеется в виду платформенная выгрузка? если так - то да, наверно прекоммит хуки основные проблемы закрывают

Да и едт тоже если мы про xml формы говорим.
Там же проблема в дублях айдишников, если дублей нет можно ничего не делать, если есть заинкрементить один из них.
https://github.com/bia-technologies/precommit4onec/blob/master/src/%D0%A1%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B8%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0XML%D0%A4%D0%BE%D1%80%D0%BC.os
Собнос все уже есть, бери пользуй и горя не знай