Я чуть другой способ использую. На канале Сообщество 1С есть видео (разные кейсы рассказывают, в т.ч. как работать с конфой вендора и пр.). Отличия: Первый коммит делаем пустой в основной ветке. Пустой имеется ввиду без каких-либо значимых файлов проекта. Т.к. я всегда использую LFS, в 1-ом коммите у меня файл .gitattributes. От 1-го коммита создаем ветку вендора. Далее действия как в видео (импорт и пр.). После вливаем ветку вендора в основную. В чем отличие спросите)... В том, что теперь у нас может быть множество вендоров (библиотеки и пр.), мы их можем версионировать и пр. грязь делать. Например, изначально это была УТ 11. Потом купили/украли какуюнить библиотеку, создали новую ветку вендора библиотеки от 1-го коммита (имя проекта всегда одинаковое). Далее вливаем ее в основную. Пы.Сы.: Изначально в конфигурации (ну и в самом конфигураторе) поддерживается мультивендорность, т.е. конфигураций поставщика также может быть больше 1. А в Вашем примере такой возможности уже нет.
Про первый недостаток не согласен - никто не мешает открыть конфигуратор, сделать сравнение / объединеине с конфигурацией поставщика, ответить утвердительно "Поставить на поддержку", в окне сравнения/объединения отключить все флаги и в таком виде объединить, после этого желательно в настройках поддержки всё рекурсивно заменить на жёлтые кубики. Вуаля - можно отдавать.
Это получится «восстановление конфигурации поставщика в ИБ» т.е. мы должны обратно поставить на поддержку и восстановить все флажки настройки поддержки для объектов. Без этого - тот кто получит ИБ из нашего гита - как бы ничего не сможет быстро сказать про поставщика и на сколько оно изменено. Разве это не недостаток? 😁
Непонятно про два workspase, ведь если в одном из них переключить ветку, затем открыть второй то там откроется та же ветка, что была открыта в первом workspase. Могли бы вы объяснить подробнее этот кейс?
Прежде всего: нужно разделить режим командной разработки (когда 2+ человека работают) от режима одиночки. 1. В командной разработке - у вас будет общий репозиторий на сервере, вы делаете 2 раза клон в разные папки, под каждую папку делаете свой воркспейс. Ничто друг другу не мешает - обновление поставщика можно делать медленно в фоне, отвлекаясь на другие задачи во втором воркспейсе 2. Когда один (и тут принципиальное что нет серверной/общей репы! Иначе это п.1) - переключил ветку на ветку вендора - выполнил обновление поставщика - и вернись назад на ту ветку где был. Во втором воркспейсе как-бы ничего не поменяется. Это ведь самый простой режим для одного разработчика - тут ни чем не отличается от Конфигуратора. Пока не закончил обновление поставщика - не можешь заниматься другими задачами. А если хочешь «один но параллельно» - то см. п.1
Я чуть другой способ использую. На канале Сообщество 1С есть видео (разные кейсы рассказывают, в т.ч. как работать с конфой вендора и пр.).
Отличия: Первый коммит делаем пустой в основной ветке. Пустой имеется ввиду без каких-либо значимых файлов проекта. Т.к. я всегда использую LFS, в 1-ом коммите у меня файл .gitattributes. От 1-го коммита создаем ветку вендора. Далее действия как в видео (импорт и пр.). После вливаем ветку вендора в основную.
В чем отличие спросите)... В том, что теперь у нас может быть множество вендоров (библиотеки и пр.), мы их можем версионировать и пр. грязь делать. Например, изначально это была УТ 11. Потом купили/украли какуюнить библиотеку, создали новую ветку вендора библиотеки от 1-го коммита (имя проекта всегда одинаковое). Далее вливаем ее в основную.
Пы.Сы.: Изначально в конфигурации (ну и в самом конфигураторе) поддерживается мультивендорность, т.е. конфигураций поставщика также может быть больше 1. А в Вашем примере такой возможности уже нет.
Разбор работы плагина плиз!
Спасибо за полезное видео! Видео про плагин тоже не помешает.
Полезное замечание про workspace. 21:52 - А почему UID-ы слетели?
Это не «слетели» сами по себе - это поставщик выпустил новую версию с другими UUID-ами.
Почему выпустил такое - не знаю.
скорее всего поставщик разрабатывал новую версию в конфигураторе и новые объекты создавал "копированием" из старой версии конфигурации
Учиться и учиться
Про первый недостаток не согласен - никто не мешает открыть конфигуратор, сделать сравнение / объединеине с конфигурацией поставщика, ответить утвердительно "Поставить на поддержку", в окне сравнения/объединения отключить все флаги и в таком виде объединить, после этого желательно в настройках поддержки всё рекурсивно заменить на жёлтые кубики. Вуаля - можно отдавать.
Это получится «восстановление конфигурации поставщика в ИБ» т.е. мы должны обратно поставить на поддержку и восстановить все флажки настройки поддержки для объектов.
Без этого - тот кто получит ИБ из нашего гита - как бы ничего не сможет быстро сказать про поставщика и на сколько оно изменено. Разве это не недостаток? 😁
Непонятно про два workspase, ведь если в одном из них переключить ветку, затем открыть второй то там откроется та же ветка, что была открыта в первом workspase. Могли бы вы объяснить подробнее этот кейс?
Прежде всего: нужно разделить режим командной разработки (когда 2+ человека работают) от режима одиночки.
1. В командной разработке - у вас будет общий репозиторий на сервере, вы делаете 2 раза клон в разные папки, под каждую папку делаете свой воркспейс. Ничто друг другу не мешает - обновление поставщика можно делать медленно в фоне, отвлекаясь на другие задачи во втором воркспейсе
2. Когда один (и тут принципиальное что нет серверной/общей репы! Иначе это п.1) - переключил ветку на ветку вендора - выполнил обновление поставщика - и вернись назад на ту ветку где был. Во втором воркспейсе как-бы ничего не поменяется. Это ведь самый простой режим для одного разработчика - тут ни чем не отличается от Конфигуратора. Пока не закончил обновление поставщика - не можешь заниматься другими задачами. А если хочешь «один но параллельно» - то см. п.1
@@Marmyshev Спасибо, стало понятно.