Краткое содержание статьи:
- Установка 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:
