Краткое содержание статьи:
- Установка Git для Windows
- Установка TortoiseGit (для удобства работы с git)
- Клонирование репозитория с файлами из облака на локальный ПК
- Внесение изменений в проект, выгрузка в файлы исходных кодов из конфигуратора
- Отправка изменений на сервер (commit и push)
- Получение измененных файлов с сервера (например, изменены другим разработчиком)
- Создание своего репозитория для новой задачи (в VSTS)
Многое уже было написано на тему контроля версий для 1С-кода, использование хранилищ конфигураций и тому подобное. Здесь я попытаюсь описать именно свой опыт и привести свои инструкции по взаимодействию с Git-репозиторием, которые писались для тех наших программистов, которые вообще никогда не работали с Git (руководства в духе "Как получить код из git-репозитория?", "Как отправить код в git-репозиторий", не будет ни форков, ни мерджа, ни фетча и т.п., только основы).
Возможно, кому-то пригодится данный опыт для начала работы.
И ни в коем случае не хочется претендовать на то, что этот опыт лучший, но для маленькой команды, он оказался довольно эффективным. С удовольствием почитаю Ваши предложения по организации работы с хранилищами при разработке "не конфигураций".
Забегая вперед, скажу, что сейчас, когда вышла вполне вменяемая и пригодная к использованию версия 1C:EDT (Enterprise Development Tools), разработку непосредственно конфигураций перенесли в него, также с выгрузкой кода в git-репозиторий. Не всё в нем гладко, но зато работа с синтаксис-помощником намного удобнее, анализ кода "на лету" и многое другое (но эта тема претендует на совершенно другую статью и не будет обсуждаться здесь, если кому станет интересно, могу выложить небольшие инструкции по работе с git из ETD не через внутренний его механизм, а также через TortoiseGit, созданию нового проекта и загрузке в него изменений, сделанных через конфигуратор).
UPDATE: статья про EDT написана, см. тут 😉
Это вместо вступления, а теперь перейдем непосредственно к теме.
Предисловие к написанным ниже инструкциям:
Основное направление разработки у нас было не создание/редактирование конфигураций, а написание отчетов, обработок и расширений. Поэтому вариант с "хранилищем конфигураций" не рассматривался, как довольно тяжелое и немного замороченное в использовании решение. Поэтому было решено использовать какое-нибудь git-хранилище для маленьких проектов (именно под отчеты/обработки/расширения).
Так как работаю в государственном образовательном учреждении с крайне ограниченным бюджетом, то выделения средств на платные репозитории у нас не предполагались. Начинали мы думать об использовании репозитория три года назад, а тогда GitHub был еще платным в случае закрытых репозиториев (сейчас, после покупки его Microsoft, закрытые репозитории сделали бесплатными, если программистов не более трех). Поэтому на тот момент мы выбрали закрытые онлайн хранилища от Microsoft (которые позволяют работать до пяти программистов бесплатно) — а именно сервисы VSTS (visual studio online).
Почему заостряю на этом внимание — скриншоты в описанных ниже инструкциях будут сделаны именно из него. Но на самом деле это абсолютно не важно. Точно также можно делать и в случае с любым другим хранилищем, например, на гитхабе. Поэтому от скриншотов из "студии" можно немного абстрагироваться и приводятся они просто, чтобы дать представление о том, что можно делать.
Если Вы захотите тоже поработать именно с этим сервисом репозиториев, то данная инструкция поможет Вам быстрее его освоить.
Итак, в нашем примере будут использоваться следующие сведения и условия:
1) Ссылка на общее хранилище (VSTS) для примера: mygit.visualstudio.com (домен третьего уровня задается при создании хранилища в данном сервисе, например, можно назвать его по имени Вашей организации)
2) Пользователь для примера: user@outlook.com (имеющий соответствующий доступ к репозиторию на чтение/запись)
3) Условимся, что в Git-репозиторий выкладывается не только исходный код, но и скомпилированная версия отчета/обработки/расширения для оперативного использования последней версии без необходимости ее "собирать из кода".
1. Установка Git для Windows
Чтобы начать работу с git, нам потребуется установить утилиту Git для Windows (рекомендуется скачивать дистрибутив с официального сайта git-scm.com/download/win).
Возможные примерные параметры при установке:
— Выбрать все компоненты
— Use Git from the Windows Command Prompt
— Use the OpenSSL library
— Checkout Windows-style, commit Unix-style line ending
— Use MinTTY (the default terminal of MSYS2)
— Enable file system caching
— Enable Git Credential Manager
2. Для удобства работы с git (не через командную строку, а через контекстное меню проводника операционной системы) рекомендуется установить TortoiseGit (я его обычно называю просто "черепашкой").
Опять же скачиваем дистрибутив с официального сайта программы: tortoisegit.org/download
При необходимости там же можно скачать русский language pack.
Установка производится без особых дополнительных настроек. В конце рекомендуется согласиться на запуск мастера настройки, где зададим пути для запуска гит и пользователя, под которым будем работать с репозиториями:
— Проверяем, что путь к ранее установленному git.exe указан верно:
— В следующем окне мастера пишем имя (под ним будут делаться коммиты — т.е. написано, кто вносил изменения в код) и свой адрес почты (учетной записи с соответствующими правами на хранилище):
— Настройку ключей в следующем окне производить не обязательно, поэтому можно пропустить, нажав "Готово":
3. Клонирование репозитория с файлами из облака на локальный ПК:
Чтобы начать работать над проектом, нужно создать его локальную "копию" у себя в системе.
Для этого переходим на сайт общих проектов VSTS (в нашем примере mygit.visualstudio.com), выбираем нужный проект, затем нажимаем Code и указываем нужный репозиторий (в данном сервисе один проект может содержать несколько репозиториев). Далее нажимаем ссылку Clone:
В открывшемся окне копируем HTTPS ссылку на репозиторий:
В проводнике создаем папку, в которой будет локально располагаться репозиторий (лучше всего назвать ее также, как репозиторий, чтобы потом было легче ориентироваться при возросшем количестве проектов), затем в контекстном меню данной папки выбираем пункт "Git Clone…" (этот пункт появляется после установки TortoiseGit):
В открывшемся окне вводим ранее скопированный URL репозитория и обязательно проверяем правильность пути папки, в которую он будет загружен (по умолчанию программа добавляет название репозитория к пути текущей папки, поэтому удалите лишнее, если потребуется):
По нажатию ОК будут запрошены учетные данные пользователя, после введения которого, репозиторий из облака загрузится в локальное хранилище.
Загрузка файлов из облака (полетела "черепашка"):
В локальную папку будет загружено содержимое выбранного репозитория:
4. Внесение изменений в проект
Работать можно как загрузив проект из файлов исходных кодов, так и со стандартным скомпилированным файлом 1С (erf и т.п.).
Например, после загрузки из облака, открываем в конфигураторе файл отчета, вносим в него изменения, как обычно.
В конце дня (или по завершению работ) после внесения изменений, например, во внешний отчет "Стартовые протоколы", необходимо обновить информацию в облаке.
Для этого любой 1С проект (отчет, обработка или расширение) необходимо выгрузить в файлы при помощи встроенной команды Действия — "Выгрузить в файлы":
В случае расширений конфигурации: пункт меню "Конфигурация" — "Выгрузить конфигурацию в файлы":
В качестве места сохранения необходимо указать локальный репозиторий. Также после выгрузки файла необходимо туда же в корень разместить оригинал рабочего файла, если работа с ним происходила в другом месте (файл 1С формата erf и т.п.), на случай, если другой разработчик не сможет "собрать" его из выгруженных файлов-исходников (XML) или нужно сразу использовать результат без перекомпилирования.
Примечание: замечено, что при выгрузке в файлы, если папка и файлы уже существовали, то они не всегда перезаписываются и остаются предыдущие версии. В этом случае необходимо выгрузить файлы в другую (пустую) папку, а затем скопировать их вручную в локальный репозиторий (предварительно очищенный). В этом случае перезапись неизмененных файлов не фиксируется, как изменение, и в коммите будут фигурировать только файлы, где было изменение кода.
5. Отправка изменений на сервер: (commit и push)
После выгрузки обновленных версий файлов из 1С нужно "зафиксировать" результат, т.е. сделать коммит.
В контекстном меню папки репозитория выбираем Git Commit:
В открывшемся окне пишем комментарий к коммиту (что мы изменили/добавили/удалили из предыдущей версии, чтобы другому разработчику при первом взгляде стало примерно понятно, чтобы было сделано) и выбираем измененные и добавленные файлы (ставим галочки у всех файлов, изменения которых нужно отправить в облако репозитория):
Затем нажимаем Commit. До отправки на сервер можно сделать несколько коммитов (отправки в облако при этом не происходит).
Теперь необходимо отправить изменения в облако, для этого в контекстном меню папки репозитория выбираем Git Sync:
В открывшемся окне видим все сделанные нами коммиты. Чтобы отправить их в облачный репозиторий, нажимаем кнопку "Push":
6. Получение измененных файлов с сервера (например, изменены другим разработчиком).
Допустим, теперь нам необходимо получить изменения, сделанные другим разработчиком. Предполагается, что локальная папка проекта у нам уже имеется (если нет, то нужно выполнить пункт 3).
В проводнике в контекстном меню локальной папки репозитория выбираем Git Sync — затем Pull (будут загружены последние версии файлов репозитория):
Ждем, когда загрузятся изменения, в итоге увидим коммиты, сделанные другими программистами, затем нажимаем Close (новые версии уже будут лежать в локальной папке).
7. Создание своего репозитория для новой задачи (пример в сервисе VSTS)
Если потребовалось создать репозиторий под новый проект, то делаем следующие действия.
На сайте облачного хранилища создаем новый репозитарий — New repository:
Указываем наименование (желательно на латинице, т.к. оно используется в URL) и соглашаемся с созданием README файла:
Далее подключаемся к нему, как написано в пункте 3, и располагаем там как выгруженные XML файлы 1С-решения, так и сам исходный файл.
Заключение:
Теперь в облаке можно смотреть историю изменения кода:
На данный момент у нас в этом хранилище около 50 проектов, работа с ними ведется постоянно тремя программистами при помощи методов, описанных выше. Преимущества использования git, наверное, описывать не требуется, так как все понимают для чего это нужно и чем это полезно. Даже если Вы являетесь единственным разработчиком проекта, всё равно рекомендуется использовать систему контроля версий, хотя бы для себя (всегда будет возможность откатиться на предыдущую версию в случае случайной порчи релиза, да и всегда самому интересно после push’а зайти да посмотреть, что Вы сегодня сделали и порадоваться своей работе, ну или наоборот расстроиться…). И не важно — код 1С это или любой другой код. Плюс можно дать доступ на просмотр коммитов и истории изменений кода Вашему начальству (менеджеру проектов или любому другому заинтересованному лицу), чтобы видели процесс Вашей работы наглядно (главное, чтобы не считали зарплату по количеству написанных строк кода :).
Что мне не нравится в вышеназванном сервисе (VSTS): нет подсветки кода 1С. Поэтому если Вы только начали этим заниматься, то рекомендую воспользоваться новым предложением от GitHub (про бесплатный репозиторий) и организовывать хранилище уже там, т.к. на нем подсветка 1С-кода уже присутствует.
Пример сравнения версий файла на GitHub:
Пример подсветки кода на GitHub:
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А что так можно было? спасибо
(1) а ETD это что
Круто Возьму на заметку.
Gitlab тоже подсвечивает код 1С.
Github, конечно, побольше, но есть подозрение, что догонят.
А на гитлабе есть бесплатные приватные репозитории.
я же правильно понимаю, что обратно собрать определенную версию конфигурации не получится из git?
(5) получится. Почему — нет?
(6) т.е вы у себя используете git и уже собирали версию?
Супер! Учтем )
Еще могу сказать, что вместо выгрузки в файлы мне, например, удобнее пользоваться
.
Правда сразу надо ставить .
И дальше поехали:
opm install precommit1c
в репозитории
precommit1c —install
а потом перед коммитом
precommit1c —git-precommit
(7) я использовал гит через , т.е. выгружал данные из хранилища.
Разок пробовал загрузить в базу для теста из репозитория. Вроде все было ок.
(10) ок, спасибо
(9) precommit1c —git-precommit, кстати нужно, чтобы видеть, что сделано перед коммитом в удобном виде.
(4) спасибо, не изучала этот сервис, надо посмотреть.
(5) постоянно собираю конфигурацию из исходников при работе с EDT (там проект только так и собирается — один программист выкладывает исходники, другой из них проект обратно собирает).
(12) да, тоже удобно. Нам просто нужно было поменьше заморочек и поудобнее отправка и получение, чтобы программисты не отвлекались на это (поэтому визуальный интерфейс по ПКМ из проводника оказался самым удобным, чем через командную строку).
(2) 1С:Enterprise Development Tools — edt.1c.ru
Среда для разработки (для 1С-кода), можно использовать вместо конфигуратора.
(11) вот пример: работа в EDT (похоже на конфигуратор) — скрин 1. По факту он работает сразу с исходниками — скрин 2 (вот что лежит в папке проекта (те же исходники, что можно сделать типовыми средствами — выгрузив из конфигуратора). При запуске проекта происходит сборка из исходников и загрузка скомпилированной конфигурации в базу.
Вопрос немного не в тему.
Использую git под linux в Visual Studio Code, и в проекте я вижу количество изменений на панели (см. скрин). А вот под Windows как не пытался, пишет система управления версиями не зарегистрирована, хотя git стоит и в консоли все работает.
(4) на github также уже можно создавать бесплатные приватные репозитарии
(19)
Столкнулся с таким же поведением. В моем случае достаточно было открыть уже иницилизированный пустой проект(git init), после этого vs code стал корректно показывать репозиторий.
Что-то у вас пункт «6. Получение измененных файлов с сервера (например, изменены другим разработчиком)» странноватый.
Все в одной ветке что ли работают?
(5)
Всё работает в обе стороны, т.е. можно как выгрузить конфигурацию в репозиторий, так и загрузить в обычном виде из оного. Огромный минус всего этого действа — скорость. В файлы конфигурация БП у меня выгружалась 20-40 минут, из файлов — и того больше. Плюс сразу в конфигурацию загрузить из файлов не получится, надо в промежуточную, откуда выгружается цфник и уже он накатывается.
(19)
У меня в винде 8.1 подхватывает без проблем, и при ините, и при клонировании, и просто если подсунуть папку с проектом
времени жрет очень много. Лучше бы придумали работу конфигуратора через xml напрямую: не cf, а репа с xml, при этом не нужно выгружать cf и т.д. Понятно, что система должна быть защищена, но есть же выход — подписывание файлов xml сертификатом и другие способы.
Например, php инструкции хранятся в файлах с расширением «php», а остальная объектная модель веб-сервиса в библиотеках. Почему нельзя так же и в 1С сделать?
(15) в обработках обычные формы используете?
(26) честно говоря, никогда не работала с обычными формами, только с управляемыми…
(22) если речь про один и тот же проект, то, если правильно поняла вопрос, да.
(25) насколько понимаю, для этого они и сделали EDT, чтобы при разработке конфигурации работать напрямую с файлами, а не с cf.
(9) precommit4onec
Precommit1c — устарел
Использовать ручную выгрузку — это жесть)
Я ещё использую батник для коммита. Контекстное меню — это долго ((
(29)ну это не серьёзно, cf никто при этом не отменял.
Вот если бы конфига из репозитория работала, подключая необходимые файлы xml…
(31) Если правильно понимаю, раз был упомянут php, Вы хотите компиляцию «на лету»? Не думаю, что это хорошо скажется на производительности. Например, в том же .Net Core перешли наоборот к концепции заранее скомпилированного кода для веб-проектов (даже HTML-шаблоны включают в dll), хотя уходящаяя ASP.Net MVC технология, похожа на PHP.
(32) Что за каша у вас в голове. Хранение исходников в текстовых файлах вообще никак к компиляции не относится. Компиляция «на лету» на производительности сказывается самым благоприятным образом для интерпритируемых языков. .Net Core заменяет .Net Frаmework, а не ASP.Net, который кстати ничем не похож на PHP. А HTML-шаблоны уже давно не используют.
(33) простите, честно, не хочется спорить 🙂 Под «HTML-шаблонами» имелись в виду Razor cshtml-страницы (но решила упростить, чтобы человек понял). То, что Core заменяет ASP.Net, вроде и не писала. А вот то, что ASP.Net не похож на PHP, это согласна. ASP.Net MVC похож, но не такой же … хотя при большом извращенном желании можно весь код в cshtml воткнуть вместо контроллера )))
(28) Ясно. Спасибо
(28) В чём тогда смысл работы через Git вместо хранилища? То же расширение подключается к хранилищу и последним gitsync 3 может выгружаться в Git автоматически. Накладных расходов намного меньше. Если мердж сразу выполняется в одну мастер-ветку и нет пул/мердж реквестов, то даже при наличии практики код-ревью это всё равно будет посткоммитное ревью, которое итак возможно при применении хранилища. Сначала помещаем в мастер-ветку и пушим (закладка в хранилище) и только после этого видим код в виде диффа между двумя коммитами в мастер-ветке (выгрузка закладки хранилища в гит).
В описанной здесь схеме в качестве преимущества прослеживается только код-ревью внешних обработок. Ну и может быть тренировка разработчиков для работы с гит, чтобы потом не сильно пугались )) Хотя первую задачу опять же лучше автоматизировать через precommit, а вторую сейчас уже лучше решать сразу через изучение EDT.
(23) Переходи на SSD
(37)
Спасибо, кэп, за этот бесценный совет, но я уже.
Простите, возможно, немного не в тему, но…
Интересна тема EDT+Git, периодически к ней возвращаюсь, но натыкаюсь на одну и ту же проблему от версии к версии EDT:
Взяли произвольную типовую конфигурацию (я экспериментирую на ЗУП 3) относительно свежей версии (конфигурация №1).
Сняли с поддержки (в самой EDT этого не сделать или я не нашел как).
Сделали из нее в EDT проект.
Ничего не меняя в проекте, заливаем его в другую произвольную конфигурацию (конфигурация №2).
Выгружаем конфигурацию №2 в .cf
Через конфигуратор заходим в конфигурацию №1. Сравниваем/объединяем с .cf из предыдущего пункта
Результат: приличный набор «различий» в исходной/результирующей конфигурациях, чаще всего выражаемых в не совсем понятных мне вещах, как то отличиях свойства «Картинка календаря» на формах и т.п.
То есть, для корректировки типовых конфигураций EDT использовать крайне затруднительно из-за неизбежных проблем с обновлениями (получим кучу отличий там где их по факту нет).
Конечно, можно использовать EDT только для разработки собственных конфигураций, в расширениях и для внешних ПФ и обработок.
Но, к сожалению, функциональность расширений пока не позволяет полностью перейти к так нужным нам доработкам типовых конфигураций минуя изменения основной конфигурации. Хотя с каждой версией платформы ситуация меняется в нужную сторону…
Может кто-то сталкивался, решил и готов поделиться кейсиком?
По своему (небольшому пока опыту): EDT очень прожорлива на ресурсы. Поэтому использование мощных процессоров (I7, Rizen 2700?), большого количества оперативы (от 32 Гб? в том числе для организации RAM-диска для временных файлов EDT) и скоростных надежных SSD приличной емкости (от 500 Гб? современные типовые конфигурации достаточно велики при выгрузке их в файлы) крайне показано при работе с этой средой разработки.
(39) Да, тоже интересует ответ на этот интересный вопрос: можно ли дорабатывать в EDT конфигурации на поддержке? Сейчас мы работаем в нем только со своими (с нуля написанными) конфигурациями. Пробовала как-то загрузить в проект EDT довольно тяжелую конфигурацию 1С:Университет ПРОФ — в итоге EDT «вообще упал и больше не встал» (но это было несколько его версий назад, надо бы попробовать снова…). На счет того, что он «жрунчик» — это да, но у меня рядом еще стоит Visual Studio, которая кушает в два раза больше, поэтому как-то уже не обращаю внимание.
(39) упс… промахнулась и ответила ниже )
(40) В декабре 2018 года (не помню просто какая тогда версия EDT была актуальна) попытки загрузить в EDT-проект ERP 2.4 заканчивались неудачно пока не докинул памяти. При общем объеме в 16 Гб + I5 + SSD ERP была вполне успешно загружена в проект менее чем за час.
Вообще, разработчики EDT очень много внимания уделяют оптимизации и ускорению работы своего продукта. Это радует и дает надежду, что продукт найдет широкое применение.
Но вот опять — что же делать с типовыми?((
(4) На gitlab много народу перебежало когда microsoft поглотил github.
Отличный мануал, спасибо. Всегда радовал механизм объединения в Git
1) до 3-5 программистов хранилище 1С итак подходит
2) выгружать/загружать вручную в .xml это зря хернёй заниматься
(0)
Отличный механизм, спасибо за публикацию.
(4) С недавнего времени гитхаб тоже предоставляет возможность работы с приватными репозиториями на бесплатном тарифе. Гитлаб же хорош тем, что серверную часть можно захостить у себя. И да, это бесплатно. Подсветка синтаксиса bsl в гитлабе встроена, так что глазкам будет приятно.
(45) Я так понимаю, что ревью кода никто не делает? Условный Вася не в курсе того, что положил в хранилище условный Петя.
Выгружать руками хранилище в xml — это именно то, что вы написали. У нас c этим успешно справляется gitsync. А уведомления о новых коммитах сразу попадают в отдельный канал mattermost. Клацнули на сообщение, перекинуло в локальный gitlab. Посмотрели, откомментировали по желанию, поставили отметку о ревью в mattermost. Таким вот нехитрым образом у нас участники группы учатся друг у друга, и всегда в курсе того, что творится в коде вне зоны их личных задач.
(42) В 1.10 они подкрутили. И даже хвастались этим в «Что нового»
(30)
Если сравнить историю развития двух проектов, то мне ваши слова кажутся крайне сомнительными:
Касательно выгрузки: Используйте хранилище 1С в связке с
(51) годное замечание, забрал слова обратно ))
Смотрел на релизы Евгения Сосны — там 2014 год. Поэтому сделал такие выводы.
Поправлю вашу первую ссылочку
К чему это замечание? Да, пробуем использовать кое-где применительно к хранилищам… Пока нет выхлопа — к сожалению никто не заинтересован, все по-старинке(((
Какое отношение к внешним обработкам/отчетам?
(50) поставила несколько дней назад 1.10 (Топаз). Действительно стал пошустрее, но не настолько, насколько хотелось бы ))
(50) Увы и ах — то что они подкрутили касается завершающих символов в программных модулях, я нашел это место в «Что нового»…
А вот такие вещи бы подправили:
(54) У них постоянные истории с завершающими символами. Недавно напоминали про «шухер», когда они так «починили» в одном из релизов 8.2 или 8.1
(52) гитсинк упомянул, так как решил, что
относится к выгрузке конфигурации с коммитом в гит, а не ко внешним обработкам. С обработками, да, скриптиками в ручном режиме.
(54) А работу с 8.3.13 и выше они добавили?
Отвечаю сам себе: нет, не добавили. Так что с EDT до сих пор работать нельзя и нельзя с ней будет работать до тех пор, пока они не синхронизируют поддержку новых платформ с их релизом.
(49) Сколько у вас стоит написать печатную форму? Как делать ревью отчета сделанного полностью на СКД?
(58) Процент написания отчётов и печатных форм у нас примерно 0.01 процента от общего объёма работы. Львиная доля работы у нас производится по конфигурациям холдинга, где действительно требуется от всех участников процесса быть в курсе. Ошибка или костыль в коде приводит к простоям огромным потерям бизнеса. А отчётики и печатные формы как правило клепаются быстро и к авариям не приводят. Но код заполнения той же печатной формы должен проходить ревью. Иначе никак — иначе смерть через лялямбу.
(59) Спасибо. Я так понимаю, что зависимость, в вашем случае, от конфигураций фирмы 1с минимальна? Напишите про то как устроена работа у вас — очень интересно. Получается, что гит используется для хранения истории версий и авторства кода, * на предыдущую версию делается руками в конфигураторе?
У меня просто ревью моего кода делать некому, а последний мой эпик фэйл был в том, что я вместо зипа завернул архив 7-зипом, служба поддержки пережила 50 телефонных звонков…
Доброе утро!
Тема весьма актуальная.
Коллеги, кто сталкивался с GIT на обычных формах (best practices)?
С уважением
(37) а чего не посоветовал сразу с pc-xt на at386 пересесть?
(61) практически не работаю с обычными формами, поэтому не подскажу, но вопрос интересный. Возможно ли это вообще с обычными формами? Поддерживает ли тот же EDT обычные формы?
(63) EDT с обычными формами не работает.
Основная проблема с обычными формами в том, что кривовато разбирается сама форма.
Причем форма переразбирается при каждом коммите.
В приложенном скриншоте пример, полученный при использовании precommit1c.
(64) Если честно можно было бы начать с выгрузки в текст из конфигуратора и записи в git.
(Нужен текстовый редактор сохраняющий в правильном формате после редактирования).
(65) последний precommit1c используется платформенную выгрузку в файлы.
Так что с выгрузкой из конфигуратора будет тоже самое.
Для редактирования файлов выгруженных можно использовать visual studio code.
Там сейчас есть дополнения, чтобы 1С-код раскрасить и т.п.
(16)нужно* использовать вместо конфигуратора.
(67) наш программист с Вами бы поспорил ))
У нас вообще смешная ситуация: я пишу проект в EDT, он этот же проект в конфигураторе (потом ему приходится загружать конфу в EDT, чтобы залить исходники на гит).
(68)
Звучит все это странно, как минимум. Если проект уже есть в EDT, в функционал которого входит использование репозитория, какой смысл пользоваться конфигуратором, в котором, мягко говоря, неудобно кодить.
(69) думаете я не задавала ему такой вопрос. Но если человеку «так удобней», то заставлять его пересаживаться на EDT, только из-за того, что я уже это сделала, не буду. Пусть кодит там, где ему хочется, лишь бы работало )
(70) Что-то сродни тому, как олдскульные кодеры кичатся виртуозным владением vim-а))
(71) а если обычные формы?
спасибо, благодаря вам оставил SourceTree и перешел на «черепашку»
(45) Это вы просто не пытались ветки делать в хранилище конфигурации, когда приходится половину конфигурации захватить чтобы добавить доработки, а все остальные 2-4 программиста сидят и кукуют. Иначе приходится делать для каждого копию базы, и работать с ней, периодически обновляя ее и перенося доработки в основное хранилище через «Сравнение/Объединение». К тому же, как показывает практика, захват в хранилище и помещение объектов обратно, далеко не быстрое занятие. Я уже и не говорю про то что периодически это хранилище отваливается, хорошо если успеешь сохранить наработки. Ну и к тому же, через гит можно удобно вести версионирование внешних дополнительных отчетов/печатных форм/обработок.
Добрый день, а можно эту команду как то программно выполнить? Допустим сделали какое то изменение во внешней обработке, загрузили его в справочник «ВнешниеОбработки» и он при записи сразу же и выгрузился в репозиторий, а нам осталось только закоммитить?
Спасибо за статью. Для себя вижу использование гита как хранилище для правил конвертации данных (КД 2.1 в основном, так как КД 3 либо расширением, либо изменением общего модуля — а там уже 1с-ное хранилище).
(75) так не выйдет
(77) а жаль
(78) как вариант — перейти на EDT, там сразу работа с исходниками происходит.
(79) у нас конфа старая ОФ, я так понял некорректно работает с ОФ. Хотелось со внешними отчетами и обработками поиграться.
Прочитал на курс1срф, что там можно через пакетный режим запускать конфигуратор для выгрузки. Вот думаю, если создадим батник и программно его запускать каждый раз при изменении, не будем ли нагружать систему и если у нас уже запущен будет конфигуратор сработает ли пакетный режим?
Почему ваш выбор остановился на git, а не, например, mercurial или svn или bazaar?
(81) как однажды мне порекомендовали более опытные коллеги — «используйте в своей работе то, что знаете лучше».
Т.к. git был хоть как-то «на слуху», а про названные Вами альтернативы я слышу практически впервые от Вас же, то ответ на вопрос очевиден 😉
(67) EDT, как спецы из раруса выяснили — жрет память, причем очень сильно, и они пока не советуют, к примеру, ERP туда заливать.
(62) Потому что нельзя так сразу перескакивать. Там еще AT286 надо было пройти.