Коллективная разработка на 1С версии 7.7 и Git
В данной статье я не буду рассматривать работу с системой контроля версий Git, для этого есть специальные ресурсы, например http://git-scm.com/book/ru. Я только расскажу тем, кто привык и любит Git, подружить старую добрую 7-ку и систему контроля версий Git.
Ни для кого не секрет, что при совместной разработке на 7-ке программисты сталкиваются со множеством проблем:
- Диалоги. Если один разработчик работает за компьютером с Windows XP, а другой, например, за компьютером с Windows 7 со включенными темами, то при редактировании модулей документов, обработок и отчетов конфигуратор 1С автоматически сдвигает элементы управления на формах вверх (на 1-2 пикселя) и уменьшает высоту формы.
- Не видно удаленных объектов. Когда новые объекты добавляются в конфигурацию, их легко заметить, но когда они удаляются из конфигурации – для того чтобы это увидеть, приходится не старый файл объединять с новым, а новый объединять со старым и смотреть какие объекты были добавлены.
- Хранение изменений. Мне всегда хотелось иметь список изменений, которые я вношу в конфигурацию, чтобы при необходимости сделать откат или посмотреть «как было». Раньше я хранил всю историю в виде MDшных файлов, но это решение не лишено недостатков: надо где-то еще хранить историю изменений в человеческом виде, лишний объем, трудно сравнивать несколько релизов.
Подготовительный этап
Установочный файл Git для Windows http://msysgit.github.io/
Для удобной работы с Git в среде Windows можно использовать надстройку TortoiseGit. https://code.google.com/p/tortoisegit/
Добавим путь к Git в переменную Path.
Сам файл конфигурации является запакованным, его можно декомпилировать в набор текстовых файлов с помощтю утилиты GComp http://1c.alterplast.ru/gcomp/
Нужная версия для работы с Git – 2.2.16 http://www.1cpp.ru/forumfiles/Attachments/gcomp_bin_2_2_16.zip.
Начало работы и немного bat’ников
Скопируем файл 1Cv7.md в папку с GComp.
Распакуем конфигурацию в папку SRC.
gcomp -d
Переименуем папку в Current и создадим там репозиторий Git.
cd Current
git init
Теперь надо добавить все файлы, которые относятся к конфигурации, в репозиторий (из текущей и вложенных папок)
git add *.mdp
git add *.1s
git add *.frm
git add *.mxl
git add *.ord
git add *.txt
git add **.mdp
git add **.1s
git add **.frm
git add **.mxl
git add **.ord
git add **.txt
Поскольку такие действия надо будет делать при каждом обновлении конфигурации, то лучше эти команды поместить в bat файл addAllFiles.bat в папке Current
После этого делаем Commit. Так у нас появляется история.
Удаляем исходный MDшник.
Далее каждый программист ведет разработку самостоятельно в 1С. Как только изменения готовы к слиянию – обновляем свой локальный репозиторий, а затем делаем Push в общий.
Обновление локального репозитория
Когда изменения готовы – копируем измененный MDшник в папку с GComp.
Декомпилируем.
Удаляем все файлы из папки Current, которые имеют отношение к конфигурации. Чтобы решить проблему с удалением.
Копируем все файлы из папки SRC в папку Current.
Добавляем все файлы из предыдущего пункта.
Делаем commit. Файлы диалогов *.frm, которые мы не трогали, не меняем (делаем revert в TortoiseGit, чтобы вернуть состояние файлов рабочей копии к состоянию последнего коммита). Это решает проблему с диалогами.
В виде bat’ника это будет выглядеть так:
if not exist = "1Cv7.MD" goto doNothing
del /S .Current*.mdp
del /S .Current*.1s
del /S .Current*.frm
del /S .Current*.mxl
del /S .Current*.ord
del /S .Current*.txt
gcomp -d
del /Q 1Cv7.MD
xcopy .SRC .Current /E /I /Y
rmdir .SRC /S /Q
cd Current
addAllFiles.bat
:doNothing
После этого можно делать push в удаленный общий репозиторий.
Сборка конфигурации
Сборка конфигурации делается командой
gcomp.exe -c -D Current
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
1. А где примеры решения конфликтов?
2. Вроде в openconf есть специальный скрипт для распаковки автоматом текущего md файла? Достаточно вызвать соответствующий макрос.
3. Каким образом обмениваетесь с коллективом?
1. Конфликты решаются как и в любом другом Git репозитории. У меня их почти не бывает, потому что разработчиков мало и делаем мы обычно разные вещи, которые друг с другом не пересекаются. Т.е. большинство коллизий разрешает сам Git.
2. Возможно. Пока не работал с ним.
3. Обмен может быть через любой удаленный репозиторий Git. Общая папка, веб-сервер, выделенный сервер, работающий по протоколу git. Самый простой вариант, когда разработчиков немного — облачное хранилище: Dropbox или Яндекс.Диск.
Прикольно, неужели 7-ка так еще популярна, не проще перейти уже на 8-ку, ведь там все уже в коробке. И все таки а как вы с md поступаете при одновременно разработке внутри конфы?
(3) alsoftik, 7ка еще более чем популярна. С точки зрения программиста 8-ка и логичнее, и удобнее во всех отношениях. Но переписывание фич, которыми успела обрасти 7-ка, и переучивание персонала — это непросто.
(4) Да я согласен, что если инструмент работает (конфа на 1С 7.7), всех устраивает и что если переходить на 1С 8 будет намного затратнее и не принесет реальных преимуществ, то лучше и не трогать, мне интересен про файл md, как с ним вопрос решается при желании одновременно с ним поработать нескольким программистам, что касается отдельных файлов (отчетов, обработок), то тут все понятно.
с md’шником все просто.
1. Делается fetch или pull запрос к общему репозиторию и получается его полная локальная копия. В случае с fetch если были ветки, то их надо еще вручную слить в локальную ветку master
2. Собирается новый md’шник на локальной машине. Потом с ним работает программист стандартными средствами конфигуратора.
3. Когда работа закончена — md’шник снова разбирается и делается commit в локальный репозиторий. Затем делается push в общий.
Спасибо! Очень интересная статья
(5) alsoftik, с CVS то же самое, у Александра Белова (abelov.com) эта технология давно работает
мне одному кажется что тема не раскрыта? затронута лишь верхушка айсберга 🙂 хотя за поднятие темы +
вообще хотелось бы подробнее услышать о самой последовательности работы, сколько разработчиков, как решаются конфликтные ситуации (к примеру конфликт с ИД новых объектов при одновременной работе нескольких разработчиков), как автоматизируете этот процесс кроме bat-ников и т.д.
больше понравился вариант от Satans Claws
God Member
В каталоге базы есть следующие каталоги:
_Модули — место хранения внешних классов (поддерживается иерархия этого каталога)
SRC — каталог, связанный с репозитарием
SRCMD — каталог декомпиляции МДшника
SRC\_Модули — каталог декомпиляции внешних классов (иерархия этого каталога поддерживается в соответствии с иерархией каталога _Модули)
<аналогично SRC\_Модули можно сделать каталоги ExtForms|PrnForms для распаковки внешних отчетов/печатных форм>
<можно сделать, например, каталог SRCImages — куда скидывать изображения>
Корнем репозитария явлется катало SRC
Запускаемые bat-файлы:
decompile.ert — декомпиляция всего
compile.ert — компиляция всего
decompile.bat сам запускает рекурсивный батник decompile_ert.bat; при необходимости, в него же (decompile.bat) дописать вызов батников для ExtForms, PrnForms, Images, etc…
decompile.bat кладется в каталог базы (рядом с МДшником); decompile_ert.bat — в каталог _Модули
compile.bat сам запускает рекурсивный батник compile_ert.bat; при необходимости, в него же (compile.bat) можно дописать вызов батников для ExtForms, PrnForms, Images, etc…
compile.bat кладется в каталог базы (рядом с МДшником); compile_ert.bat — в SRC\_Модули
compile_ert.bat имеет баг: если у внешнего ert-класса (или просто обработки) есть описание, то после компиляции создается пустой каталог с именем ert-шки и файлом описание.txt внутри.
Вероятно, это может иметь последствия при декомпиляции.
Показать
Belomor, раз уж о WinCVS (8) вспомнили — добавлю: — (один из) основоположников.
тоже очень актуально про разрешение конфликтов.