Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git
Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою "копию" проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).
Комментарии
Избранное
Подписка
Сортировка:
Древо
"Меня часто спрашивают... с хранилища на использование системы контроля версий (СКВ)? Отвечаю на первую часть вопроса. ..."
тут нужно остановиться и воспроизвести слово "зачем"
зачем тонна софта в инфраструктуре по типу карточного домика и для каких задач?
Я бы понял если нужно разгребать тучу коммитов и форков драйвера или утилиты для Linux (для чего собсто git и делался),
а в 1С зачем? Устраивать самому себе стрельбу в ногу - когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул, а ты такой полдня в поиске проблемы вместо нажатия на кнопку "Поместить в хранилище"?
Да ну подождите вы EDT
тут нужно остановиться и воспроизвести слово "зачем"
зачем тонна софта в инфраструктуре по типу карточного домика и для каких задач?
Я бы понял если нужно разгребать тучу коммитов и форков драйвера или утилиты для Linux (для чего собсто git и делался),
а в 1С зачем? Устраивать самому себе стрельбу в ногу - когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул, а ты такой полдня в поиске проблемы вместо нажатия на кнопку "Поместить в хранилище"?
Да ну подождите вы EDT
(39) Когда отомрёт УПП, наша организация перестанет использовать УТ 10.3? Не совсем понял ход мысли. Конкретно в нашей организации используется git + precommit. Основная конфигурация на базе сильно переписанной УТ 10.3
Что у нас должно поменяться со смертью УПП и для чего нам EDT?
Что у нас должно поменяться со смертью УПП и для чего нам EDT?
(2) никто не утверждает, что описанная метода - панацея. Нравится хранилище и кажется более надежным? - пожалуйста, никто по рукам бить не будет.
Но лично я ощутил на себе и своих разработчиках массу плюсов в использовании Git, поэтому и родилась идея этой серии статей.
Куча софта? Да не такая уж и куча, если учесть, какой кучей вы уже пользуетесь. Просто для вас это стало естественным. Пройдёт совсем немного времени, и так же естественно будет открыть VS Code для редактирования модуля.
Глюки? Бугага! За два года ни разу ничего не глюкануло! А вот хранилище глючит с завидной регулярностью. И приходится сидеть ждать, пока админы что-то починят на серверах и роутерах, пока можно будет снова захватить или поместить объект. А это время, а это деньги.
Но лично я ощутил на себе и своих разработчиках массу плюсов в использовании Git, поэтому и родилась идея этой серии статей.
Куча софта? Да не такая уж и куча, если учесть, какой кучей вы уже пользуетесь. Просто для вас это стало естественным. Пройдёт совсем немного времени, и так же естественно будет открыть VS Code для редактирования модуля.
Глюки? Бугага! За два года ни разу ничего не глюкануло! А вот хранилище глючит с завидной регулярностью. И приходится сидеть ждать, пока админы что-то починят на серверах и роутерах, пока можно будет снова захватить или поместить объект. А это время, а это деньги.
(55) Гит позволяет очень быстро ответить на вопрос - кто и когда добавил эту строчку кода. git-blame
После одного случая, где для поиска автора и породившей изменение задачи потребовалось более 6 ти часов, для меня это стало очень большим преимуществом.
С хранилищем - при большой истории изменения объекта - печаль и боль.
После одного случая, где для поиска автора и породившей изменение задачи потребовалось более 6 ти часов, для меня это стало очень большим преимуществом.
С хранилищем - при большой истории изменения объекта - печаль и боль.
когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул
Да ну подождите вы EDT
тем временем в комментах с новостями про EDT люди пишут.
"зачем нам EDT, вдруг он у нас отвалится и мы не сможем сдать подсистему"
Я заметил, что 1Сники очень консервативные люди и очень сильно боятся чего-то нового, постоянно аргументируя тем, что все атвалицтся и они бедненькие не успеют чего-то там, при этом то же хранилище, скажем так, немного не стабильно порой, да в принципе все кто связан с 1С уже привыкли страдать
Юзеры, которые уже давно не удевляются тому, что "1С глючит", разработчики, которые ходят по отделам и спрашивают, "а кто это написал" и тд.
Собственно хайп вокруг git + 1C возник именно на этой почве, людям и бизнесу в целом надоело страдать в то время, когда коллеги из других направлений разворачивают "гиты", "сиай", пишут тесты и крепко спят по ночам, при этом еще и на выходных отдыхают.
Есть конечно 1 кейс, при котором git скорее будет излишним усложнением:
Количество разработчиков ~1 и в вашей компании баги и простои 1С не сильно сказываются на работоспособности бизнеса, если это так, то тут действительно git возможно не нужен, хотя даже при таком раскладе, версионировать обработки \ ВПФ и тд без гита в принципе сложно сейчас.
В части стартового пинка одинэсников в сторону СКВ все очень круто. Толково написано, все по делу, очень емко и информативно - пять с плюсом короче.
Много вопросов за кадром, но вероятно они будут освещены в следующих статьях.
Но один все же меня мучает: "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С" - это как? Хоть в двух словах? Как, например, быть с созданием и редактированием форм в "основном инструменте"?
Много вопросов за кадром, но вероятно они будут освещены в следующих статьях.
Но один все же меня мучает: "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С" - это как? Хоть в двух словах? Как, например, быть с созданием и редактированием форм в "основном инструменте"?
(5) Насколько наблюдал за чужим опытом на инфостарте.
VSCode используют в двух сценариях:
1) В паре с OneScript
2) Когда вы выгрузили свою конфигурацию в git разобрав её на исходный код - для поиска нужной вам информации. Тк поиск в самом конфигураторе может быть несколько продолжительным.
VSCode используют в двух сценариях:
1) В паре с OneScript
2) Когда вы выгрузили свою конфигурацию в git разобрав её на исходный код - для поиска нужной вам информации. Тк поиск в самом конфигураторе может быть несколько продолжительным.
Отличная серия статей намечается.
Гитом активно пользуюсь, но все руки никак не доходили настроить настроить разбор обработок на исходный код, так и храню бинарниками.
Было бы здорово, если бы 1с добавила в конфигуратор кнопочку для выгрузки в git (EDT очень не нравится).
Ну а пока, видимо, придется заморочиться и разобраться с Precommit1C
Гитом активно пользуюсь, но все руки никак не доходили настроить настроить разбор обработок на исходный код, так и храню бинарниками.
Было бы здорово, если бы 1с добавила в конфигуратор кнопочку для выгрузки в git (EDT очень не нравится).
Ну а пока, видимо, придется заморочиться и разобраться с Precommit1C
(15) Вы, кажется, меня не понимаете.
Я не утверждаю, что невозможно положить исходники обработки в git.
Утверждать подобное было бы вдвойне глупо в комментариях такой статьи.
Судя по всему все сведется к попытке подружить precommit1C с gitKraken.
Просто руки до сих пор не дошли.
Я говорю об отсутсвии "пердолинга":
Я не утверждаю, что невозможно положить исходники обработки в git.
Утверждать подобное было бы вдвойне глупо в комментариях такой статьи.
Судя по всему все сведется к попытке подружить precommit1C с gitKraken.
Просто руки до сих пор не дошли.
Я говорю об отсутсвии "пердолинга":
Прикрепленные файлы:
(8) Особой заморочки с precommit вроде и нет.
Как было написано в статье, скопировать его файлы в каталог хуков. И все на этом.
Потом держать открытым SourceTree и время от времени делать commit (и пуш может быть).
Автоматически из конфига не получится.
Как было написано в статье, скопировать его файлы в каталог хуков. И все на этом.
Потом держать открытым SourceTree и время от времени делать commit (и пуш может быть).
Автоматически из конфига не получится.
(17) Ага, именно так я и планировал поступить очень давно.
Только вместо SourceTree (нет под линь, а я какт предпочитаю инструменты которые есть и под пингвина и под форточку) использую GitKraken
Нужно было придумать некий git hook (как написано в статье) который перед коммитом будет разбирать обработки.
Эта статья вышла очень кстати и вероятно поможет наконец сделать то, что стоило сделать давным-давно.
Только вместо SourceTree (нет под линь, а я какт предпочитаю инструменты которые есть и под пингвина и под форточку) использую GitKraken
Нужно было придумать некий git hook (как написано в статье) который перед коммитом будет разбирать обработки.
Эта статья вышла очень кстати и вероятно поможет наконец сделать то, что стоило сделать давным-давно.
Хорошая статья, не хватает только сравнения разных git-серверов (хостингов), в чем плюсы минусы, какие особенности у тех и у других. И ещё, хорошо бы уделить внимание не только к подключению к существующим проектам, но о создании собственных проектов и репозиториев (с уже имеющимися локальными исходниками).
(19)
Все что есть, реализует git, по сути это как сравнивать одноклассники с вк, вроде интерфейс разных цветов, а суть одна и таже.
GitLab вы можете поднять на локальном сервере. GitHub довольно популярен для публичных репозиториев.
Если хотите практически бесплатно и большой любитель похардкодить приватные данные - используйте GitLab.
Самый простой способ:
1) Создаете новый репозиторий прям через web интерфейс
2) Клонируете его к себе на диск
3) Закидываете свои локальные данные в появившуюся папку, коммитите (git commit -m "first push")
4) Толкаете (git push)
Хорошая статья, не хватает только сравнения разных git-серверов (хостингов), в чем плюсы минусы, какие особенности у тех и у других.
Все что есть, реализует git, по сути это как сравнивать одноклассники с вк, вроде интерфейс разных цветов, а суть одна и таже.
GitLab вы можете поднять на локальном сервере. GitHub довольно популярен для публичных репозиториев.
Если хотите практически бесплатно и большой любитель похардкодить приватные данные - используйте GitLab.
И ещё, хорошо бы уделить внимание не только к подключению к существующим проектам, но о создании собственных проектов и репозиториев (с уже имеющимися локальными исходниками).
Самый простой способ:
1) Создаете новый репозиторий прям через web интерфейс
2) Клонируете его к себе на диск
3) Закидываете свои локальные данные в появившуюся папку, коммитите (git commit -m "first push")
4) Толкаете (git push)
(46) Если что, установка gitlab'а на домашнем/рабочем сервере крайне проста, только он из коробки жрет очень много.
Можете сразу списывать 4 гига оперативы. Но мне не жалко, ведь жаба давит ежемесячно платить гитхабу 7$ за приватных репозиториев (а мне нужно больше) С:
Можете сразу списывать 4 гига оперативы. Но мне не жалко, ведь жаба давит ежемесячно платить гитхабу 7$ за приватных репозиториев (а мне нужно больше) С:
Прикрепленные файлы:
Классная статья, с нее начинал работу с этими инструментами. Хорошо, что теперь есть и на Инфостарте.
Пара моментов. Функционал deployka сейчас переехал в runner. Использовать стало удобнее. Приведен к стандарту формат длинных и коротких ключей. Сейчас есть смысл переписать команды с deployka и vrunner на runner и рекомендовать использование последнего.
При установке git для работы с 1С все же лучше выставлять настройки отличные от настроек по умолчанию. Лучше выставлять commit as is + checkout as is. Перегонять окончания строк в Unix-style и обратно кажется нецелесообразной тратой ресурсов, особенно при работе с большими конфигурациями на 5-7 миллионов строк. Также лучше не отказываться от инструментов, входящих в пакет git, они выручают.
Возможно покажется полезной еще такая информация. Наиболее удобным способом работы c git в сочетании с 1С кажется даже не использование Gitlab/Github/Bitbucket, а создание репозиториев на собственном сервере и работа с ними либо напрямую как с локальным каталогом, либо через ssh-сервер. При этом упрощается обслуживание и контроль.
Такие инструменты как Upsource и Fisheye/Crucible позволяют работать с Native репозиториями, расположенными прямо на локальных дисках. Мы получаем все преимущества облачных систем внутри компании. За исключением пул/мердж реквестов, которые при работе с хранилищем и не нужны. Экономим на дорогих лицензиях Bitbucket или Github Server, нет необходимости обслуживать Linux / Docker для того, чтобы хостить GitLab.
В случае совместной работы с репозиторием лучше все таки поставить ssh-сервер. Для Windows перебирал разные варианты ssh-серверов и самым удобным и беспроблемным в отношении именно git оказался Bitvise. Дополнительным плюсом являются оповещения о входящих подключениях, попытках успешной и не успешной авторизации, это сильно ускоряет первоначальную настройку сервера. Поставить для изучения - бесплатно. Для компании - копейки. Есть не очевидные тонкости настройки, если будет интересно - пишите, расскажу.
По темам для следующих публикаций. Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт. Какие сложности при этом возникают, особенности настройки и организации процесса. Возможно вторая тема "Организация Git workflow в 1С-разработке" как-то затронет этот вопрос?
Также интересна тема "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С". Буду ждать. Сейчас использую VSC для скриптов OneScript, пайпланов Jenkins и файлов Gherkin. Было бы интересно узнать, можно ли расширить область применения VSC в отношении именно разработки на 1С.
Пара моментов. Функционал deployka сейчас переехал в runner. Использовать стало удобнее. Приведен к стандарту формат длинных и коротких ключей. Сейчас есть смысл переписать команды с deployka и vrunner на runner и рекомендовать использование последнего.
При установке git для работы с 1С все же лучше выставлять настройки отличные от настроек по умолчанию. Лучше выставлять commit as is + checkout as is. Перегонять окончания строк в Unix-style и обратно кажется нецелесообразной тратой ресурсов, особенно при работе с большими конфигурациями на 5-7 миллионов строк. Также лучше не отказываться от инструментов, входящих в пакет git, они выручают.
Возможно покажется полезной еще такая информация. Наиболее удобным способом работы c git в сочетании с 1С кажется даже не использование Gitlab/Github/Bitbucket, а создание репозиториев на собственном сервере и работа с ними либо напрямую как с локальным каталогом, либо через ssh-сервер. При этом упрощается обслуживание и контроль.
Такие инструменты как Upsource и Fisheye/Crucible позволяют работать с Native репозиториями, расположенными прямо на локальных дисках. Мы получаем все преимущества облачных систем внутри компании. За исключением пул/мердж реквестов, которые при работе с хранилищем и не нужны. Экономим на дорогих лицензиях Bitbucket или Github Server, нет необходимости обслуживать Linux / Docker для того, чтобы хостить GitLab.
В случае совместной работы с репозиторием лучше все таки поставить ssh-сервер. Для Windows перебирал разные варианты ssh-серверов и самым удобным и беспроблемным в отношении именно git оказался Bitvise. Дополнительным плюсом являются оповещения о входящих подключениях, попытках успешной и не успешной авторизации, это сильно ускоряет первоначальную настройку сервера. Поставить для изучения - бесплатно. Для компании - копейки. Есть не очевидные тонкости настройки, если будет интересно - пишите, расскажу.
По темам для следующих публикаций. Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт. Какие сложности при этом возникают, особенности настройки и организации процесса. Возможно вторая тема "Организация Git workflow в 1С-разработке" как-то затронет этот вопрос?
Также интересна тема "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С". Буду ждать. Сейчас использую VSC для скриптов OneScript, пайпланов Jenkins и файлов Gherkin. Было бы интересно узнать, можно ли расширить область применения VSC в отношении именно разработки на 1С.
(22)
Меня наоборот, очень интересуют реальные схемы работы Git + Хранилище. Чтобы рабочая база не из гита напрямую собиралась, а чтобы релизы через хранилище шли. Общая схема вроде понятна, но про реальные наработки было бы интересно послушать.
Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт.
Меня наоборот, очень интересуют реальные схемы работы Git + Хранилище. Чтобы рабочая база не из гита напрямую собиралась, а чтобы релизы через хранилище шли. Общая схема вроде понятна, но про реальные наработки было бы интересно послушать.
(26)
Цитата отсюда:
Т.е. из гита собрать cf, cf в хранилище, из хранилища в рабочую. Вроде всё реально.
Вот .
Я же сказал вроде. Разработчики в гите, а релизы в рабочую - через хранилище.
Цитата отсюда:
собрать cf, захватить все объекты, объединить с cf через MergeConfig.xml, выполнить коммит. все через пакетный запуск конфигуратора или v8runner или vanessa-runner
Т.е. из гита собрать cf, cf в хранилище, из хранилища в рабочую. Вроде всё реально.
Вот .
(27) Сам знаю, что вроде все реально :) Интересует боевой опыт бывалых офицеров :)
Что-то этот пункт мне не сильно нравится. Почему не собирать штатно напрямую в конфу с подключенным хранилищем и захваченными объектами?
Судя по всему, при подключенном хранилище это сделать не получится... Тогда понятно.
объединить с cf через MergeConfig.xml
Что-то этот пункт мне не сильно нравится. Почему не собирать штатно напрямую в конфу с подключенным хранилищем и захваченными объектами?
Судя по всему, при подключенном хранилище это сделать не получится... Тогда понятно.
(26)
ЗЫ. Я вообще не понимаю, как люди на самом деле работают. Неужели все продакшн
Я релизы делаю из хранилища.
Для подготовки файлов поставки есть отдельная файловая база (1С:ERP), напрямую неподключенная к хранилищу. Когда нужно выпустить релиз, в командной строке выполняю следующую команду:
deployka loadrepo /FD:\1C_Data\erp_delivery D:\1C_Storage\erp -storage-user Администратор -v8version 8.3.10
В результате выполнения команды, конфигурация забирается из хранилища, и далее делаю поставки обычным стандартным образом в конфигураторе.
Спрашивайте, если что-то осталось непонятно.
ЗЫ. Я вообще не понимаю, как люди на самом деле работают. Неужели все продакшн
Я релизы делаю из хранилища.
Для подготовки файлов поставки есть отдельная файловая база (1С:ERP), напрямую неподключенная к хранилищу. Когда нужно выпустить релиз, в командной строке выполняю следующую команду:
deployka loadrepo /FD:\1C_Data\erp_delivery D:\1C_Storage\erp -storage-user Администратор -v8version 8.3.10
В результате выполнения команды, конфигурация забирается из хранилища, и далее делаю поставки обычным стандартным образом в конфигураторе.
Спрашивайте, если что-то осталось непонятно.
Спасибо за статью! Надеюсь, как 1сник далекий от гитов и едт'ов, что в следующих статья будут практические кейсы, когда гиты помогают, а хранилище или не умет, или не тянет, или еще что. Чтобы можно было как-то оценить, что да - хранилище в этом случае фигня, а гиты - торт!
Я пока сижу в хранилищах, и не шибко понимаю, вот эти все описанные в итоге в статье, действия, они по итогу - какое существенное преимущество дают, относительно того же хранилища. Читал ресурс по едт от 1С, типа объект могут править сразу несколько человек и на этапе мерджа, или как-то так, можно типа разрулить все круто. Но опять же, я пока не столкнулся с этими проблемами.
Может кто из коллег подскажет уже сейчас, когда есть смысл в практической работы переезжать с хранилищ на эти гиты, деплойки, какие-то в раннеры и все что в статье и комментах описано?
Я пока сижу в хранилищах, и не шибко понимаю, вот эти все описанные в итоге в статье, действия, они по итогу - какое существенное преимущество дают, относительно того же хранилища. Читал ресурс по едт от 1С, типа объект могут править сразу несколько человек и на этапе мерджа, или как-то так, можно типа разрулить все круто. Но опять же, я пока не столкнулся с этими проблемами.
Может кто из коллег подскажет уже сейчас, когда есть смысл в практической работы переезжать с хранилищ на эти гиты, деплойки, какие-то в раннеры и все что в статье и комментах описано?
(29)
Если сравнить возможности git и хранилища конфигурации 1С, то для git можно выделить ряд полезных особенностей:
git -- распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.
git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.
Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая "git flow".
Хранение любой информации. В отличие от хранилища 1С, в git можно хранить любую информацию (желательно текстовую, но это не обязательно). Поэтому при использовании git возникает возможность хранить не только конфигурацию, но и все внешние отчеты, обработки и другую сопутствующую информацию.
git -- распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.
git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.
Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая "git flow".
Хранение любой информации. В отличие от хранилища 1С, в git можно хранить любую информацию (желательно текстовую, но это не обязательно). Поэтому при использовании git возникает возможность хранить не только конфигурацию, но и все внешние отчеты, обработки и другую сопутствующую информацию.
Прикрепленные файлы:
Прошу автора более полно раскрыть идею использования (упомянутого им чуть ли не как мастхэв) VS Code. Так как это не очевидно (комментарии других это подтверждают).
По чисто субъективной оценке взятой с потолка 95% коллективной работы программистов 1С сводится к изменению структуры метаданных, доработке форм и макетов (в первую очередь СКД, но и обычных печатных форм тоже море). Как тут может помочь этот умный блокнот? Пара комментаторов заметила, что там скорость текстового поиска выше, но лично для меня во всех рабочих конфигурациях это не является проблемой (с ERP не работал - возможно там поиск действительно долгий особенно без SSD-диска и с маленькой оперативкой).
По чисто субъективной оценке взятой с потолка 95% коллективной работы программистов 1С сводится к изменению структуры метаданных, доработке форм и макетов (в первую очередь СКД, но и обычных печатных форм тоже море). Как тут может помочь этот умный блокнот? Пара комментаторов заметила, что там скорость текстового поиска выше, но лично для меня во всех рабочих конфигурациях это не является проблемой (с ERP не работал - возможно там поиск действительно долгий особенно без SSD-диска и с маленькой оперативкой).
(51) очень похоже, что статья написана по результатам прохождения курса Профессиональная разработка в 1С от Серебряной Пули (вольный пересказ).
В курсе использовали VSCode для вспомогательных целей (не для редактирования исходников 1С): например, для подготовки настроечных файлов для вспомогательных утилит тестирования, подготовки поставок, написания пайплайн-файлов для дженкинса и чего-то еще.
В курсе использовали VSCode для вспомогательных целей (не для редактирования исходников 1С): например, для подготовки настроечных файлов для вспомогательных утилит тестирования, подготовки поставок, написания пайплайн-файлов для дженкинса и чего-то еще.
Скажите сразу, вы в следующих статьях расскажете о практической стороне (step-by-step) как выполнять слияния в git вручную и в EDT?
Нигде в подобных статьях или циклах статей я не нашел ответа на этот вопрос.
Три ветки maste, release, develop. от develop на задачу делаем ветку, потом сливаем ветку задачи с develop.
Слияние - как его делать? Ведь код модуля это далеко не все, что есть в разработке на 1С. То есть мы текстовые файлы конфигурации вручную объединяем или все таки cf сравнением-объединением вливаем в develop? может EDT умеет это делать из коробки и понятно и наглядно?
Затем, когда из develop в release сливаем тоже - как? и затем в master.
Сидит специально обученный человек с квадратной головой, который все конфликты и мержи разрешает?
Делается ли сборка cf из файлов конфигурации или файлы отдельно для комментариев и Jira. а cf отдельно для нормального объединения изменений?
Эти вопросы все гуры по git как-то обходят стороной, а именно они не дают принять решение о переходе на трушные технологии разработки.
Нигде в подобных статьях или циклах статей я не нашел ответа на этот вопрос.
Три ветки maste, release, develop. от develop на задачу делаем ветку, потом сливаем ветку задачи с develop.
Слияние - как его делать? Ведь код модуля это далеко не все, что есть в разработке на 1С. То есть мы текстовые файлы конфигурации вручную объединяем или все таки cf сравнением-объединением вливаем в develop? может EDT умеет это делать из коробки и понятно и наглядно?
Затем, когда из develop в release сливаем тоже - как? и затем в master.
Сидит специально обученный человек с квадратной головой, который все конфликты и мержи разрешает?
Делается ли сборка cf из файлов конфигурации или файлы отдельно для комментариев и Jira. а cf отдельно для нормального объединения изменений?
Эти вопросы все гуры по git как-то обходят стороной, а именно они не дают принять решение о переходе на трушные технологии разработки.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.