Merge branch 'master' into develop

docs/Git-LFS.md

@@ -0,0 +1,28 @@
+Для увеличения быстродействия репозитория Git можно использовать расширение __git lfs__ (https://git-lfs.github.com)
+
+Если используется сервер репозиториев Git, необходимо убедиться, что он поддерживает это расширение и включить настройки для проекта. Например, GitLab, GitHub, BitBucket - поддерживают.
+
+Выполнить начальную настройку репозитория до выполнения первого коммита:
+
+```bash
+git lfs install
+```
+
+Включить отслеживание бинарных файлов конфигурации
+```bash
+git lfs track "*.cf"
+git lfs track "*.bin"
+git lfs track "*.png"
+git lfs track "*.gif"
+git lfs track "*.bmp"
+git lfs track "*.jpg"
+git lfs track "*.zip"
+```
+В этом примере - все файлы конфигураций поставщиков, файлы макетов с "Двоичными данными" и картинки из конфигурации попадут в lfs.
+
+Например, чтобы переносить в LFS только некоторые типы файлов с расширением `*.bin` можно включить отслеживание только шаблонов и модулей без исходного кода по маске:
+
+```bash
+git lfs track "*/Ext/Template.bin"
+git lfs track "*/Ext/Module.bin"
+```

docs/Home.md

@@ -0,0 +1,29 @@
+# 1С:ГитКонвертер
+
+Конфигурация предназначена для односторонней синхронизации хранилища конфигурации "1С:Предприятия" с репозиторием Git и последующим переходом на разработку в [1C:Enterprise Development Tools (1C:EDT)](http://v8.1c.ru/overview/release_EDT_18/) с сохранением истории.
+
+
+### Основные возможности
+
+* Конвертирование существующего хранилища конфигурации 1С в репозиторий Git в формате 1C:EDT
+* Обновлять изменения из хранилища 1С в репозиторий Git
+* Параллелизировать загрузку истории хранилища из копий хранилища
+* Ограничение нагрузки на сервер с помощью очередей
+* Возможно "сращивать" историю в Git, если хранилище конфигураций "1С:Предприятия" обрезалось или начиналось заново.
+* Создание корректной истории переименования объектов метаданных (см. [Как это работает](Как-это-работает#Коммит-в-git))
+* Выгружать только изменения конфигурации. Доступно для Платформы 8.3.10 и выше, требуется использовать "очереди"
+* Создание сквозной история изменений для "хранилищ исправительных версий" если вы используете [Технологию разветвленной разработки конфигураций](https://its.1c.ru/db/v8std/content/2149184358/hdoc) или аналогичный процесс - хранилище версии можно загружать в "ветку" Git, получив сквозную историю в ветке.
+* Возможность автоматически указывать Git теги при изменении версии конфигурации.
+* Поддержка конвертации разных хранилищ в разные ветки одного репозитория на различных версиях Платформы и различных версиях 1C:EDT.
+
+### Необходимые компоненты
+
+* Конфигурацию можно запустить, используя 1C:Enterprise Development Tools 1.10 (https://releases.1c.ru/project/DevelopmentTools10)
+* Платформа 1С:Предприятия 8.3.12 и выше (https://releases.1c.ru/project/Platform83)
+* СУБД, поддерживаемая 1С:Предприятием
+* OS Windows 7 или выше, ОС Linux и macOS - в бета-режиме.
+
+## Полезные ссылки
+
+* Сайт 1C:EDT [https://edt.1c.ru](https://edt.1c.ru)
+* Книга он-лайн [Групповая разработка в 1C:Enterprise Development Tools](https://edt.1c.ru/upload/docs_git/EDT&GIT.html) - см. Глава 6 - про 1С:ГитКонвертер, Постепенный переход на разработку в EDT

docs/_Sidebar.md

@@ -0,0 +1,32 @@
+[Начало](home)
+
+* [Как это работает?](Как-это-работает)
+* [Начальная настройка](Начальная-настройка)
+  * [Настройка Windows](Настройка-Windows)
+  * [Настройка Linux](Настройка-Linux)
+  * [Настройка сервера 1С](Настройка-сервера-1С)
+  * [Настройка базы ГитКонвертера](Настройка-базы-ГитКонвертера)
+
+* [Настройка конвертации хранилища 1С](Настройка-конвертации-хранилища-1С)
+  * [Параметры конвертации](Параметры-конвертации)
+  * [Авторизация в сервере Git](Авторизация-в-сервере-Git)
+  * [Дополнительная настройка репозитория Git](Дополнительная-настройка-репозитория-Git)
+    * [Символы окончания строк](Символы-окончания-строк)
+    * [Git LFS](Git-LFS)
+  * [Информация пользователей](Информация-пользователей)
+* Дополнительные возможности
+  * [Копии хранилища](Копии-хранилища)
+  * [Очереди выполнения](Очереди-выполнения)
+  * [Расширения](Расширения)
+
+* [Сценарии применения](Сценарии-применения)
+  * [Начать работу в EDT, не конвертируя все предыдущие версии хранилища](Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища)
+  * [Максимум скорости на историю](Максимум-скорости-на-историю)
+  * [Оперативное слежение за разработкой](Оперативное-слежение-за-разработкой)
+  * [Сращивание истории из нескольких хранилищ](Сращивание-истории-из-нескольких-хранилищ)
+  * [Сквозная история в ветках](Сквозная-история-в-ветках)
+
+* [Обновление с версии 1.0.4](Обновление-с-версии-1.0.4)
+  * [Конвертация выгрузки 1С:Предприятия в формат 1C:Enterprise Development Tools](Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools)
+
+* [Если что-то пошло не так (FAQ)](Если-что-то-пошло-не-так-FAQ)

docs/Авторизация-в-сервере-Git.md

@@ -0,0 +1,29 @@
+1С:ГитКонвертер позволяет конвертировать историю в локальный репозиторий или в локальный с отправкой изменений в удаленный репозиторий.
+
+В качестве сервера Git вы можете использовать одну из публичных систем управления репозиториями, которые есть в интернете. Например, **GitLab**, **GitHub**, **BitBucket** и др. Их достоинство заключается в том, что от вас не требуется предварительная установка и настройка программного обеспечения. Недостатком является то, что для размещения удалённого приватного (не публичного) репозитория вам, скорее всего, придётся использовать платный аккаунт.
+
+В то же время, например, **GitLab** имеет _бесплатную_ версию, которую вы можете скачать и установить на сервере своей организации. Так же GitLab.com предоставляет бесплатно возможность создавать приватные репозитории с некоторыми ограничениями.
+
+## Варианты авторизации
+
+### Простая авторизация (логин и пароль)
+
+Это авторизация в 1С:ГитКонвертере сделана по умолчанию для простоты адаптации разработчиков 1С.  В форме настроек хранилища необходимо указать:
+* адрес сервера Git
+* логин и пароль для доступа на сервер. 
+
+Если локальный репозиторий уже был создан без настроек удаленного репозитория - необходимо нажать на кнопку **Установить адрес репозитория Git** рядом с адресом сервера Git в форме настроек хранилища.
+
+Учтите, что логин и пароль - хранятся в базе данных 1С:ГитКонвертера, а так же в файле настроек `/.git/config` в репозитории. Поэтому безопасность этой информации обеспечивается доступом к самому серверу на котором расположен 1С:ГитКонвертер.
+
+### Авторизация по ssh
+
+Этот способ немного сложнее настраивать, но все серверы Git поддерживают такой способ авторизации по умолчанию. При этом, в 1С:ГитКонвертере нет ограничений использовать, настроенный самостоятельно, доступ по ssh. В форме настроек хранилища достаточно указать адрес сервера Git.
+
+**Внимание!** Настройку авторизации по протоколу SSH необходимо выполнять для пользователя ОС под которым запущен сервер 1С, т.к. соединение с Git-сервером будет выполняться под этим пользователем.
+
+### Авторизация Windows Credential Manager
+
+Аналогично способу `ssh` можно использовать авторизацию с помощью `Windows Credential Manager` настроив доступ вручную для пользователя под которым запущен сервер 1С:Предприятия. В форме настроек хранилища в 1С:ГитКонвертере аналогично - достаточно указать адрес и произвольные символы в поле логина и пароля.
+
+### [Подробнее о протоколах](https://git-scm.com/book/ru/v2/Git-на-сервере-Протоколы)

docs/Версия-Платформы-Хранилища.md

@@ -0,0 +1,14 @@
+Расширение позволяет конвертировать в формат EDT на одной версии 1С:Предприятия, а для подключения к хранилищу использовать другую версию Платформы.
+
+### Подробней
+В процессе разработки существует необходимость менять версии Платформы (в т.ч. версию сервера Хранилищ 1С), при этом есть ограничение со стороны EDT - что версии поддерживаются не все, а только выпущенные на момент выпуска EDT. Обычно, необходимо версию Платформы для выгрузки в xml и версию сервера хранилищ 1С держать одинаковой.
+В некоторых случаях, команда разработки хотела бы использовать сервер на версии Платформы который EDT не поддерживает, при этом конфигурация в хранилище находится в режиме совместимости с поддерживаемой EDT версией Платформы.
+
+Другой сценарий - когда команда разработки привязана к строго определенной сборки (в 4-й цифре) 1С:Предприятия и не имеет возможности для конвертации в формат EDT использовать более свежую версию, в которой, например, исправлены ошибки выгрузки.
+
+### Настройка
+
+1. Установите расширение в ИБ ГитКонвертера
+2. В карточке настройки конвертации хранилища - появляется дополнительное поле "Версия хранилища" и прежнее поле "Версия выгрузки".
+3. В "Копиях хранилища" так же можно указывать версию Платформы сервера хранилищ отличную от версии выгрузки.
+

docs/Дополнительная-настройка-репозитория-Git.md

@@ -0,0 +1,19 @@
+По умолчанию создается файл настроек `.gitattributes` в который добавлены настройки бинарных файлов:
+
+```
+*.bin binary
+*.axdt binary
+*.addin binary
+```
+
+По умолчанию создается файл исключений `.gitignore`, в который добавляются файлы `DumpFilesIndex.txt` и `ConfigDumpInfo.xml` - не требуемые для работы с исходными файлами конфигурации 1С.
+
+Если репозиторий был создан с помощью кнопки в карточке хранилища, в локальный конфиг репозитория добавляются настройки для более комфортной работы:
+
+```bash
+git config --local core.quotepath false
+git config --local gui.encoding utf-8
+git config --local i18n.commitEncoding utf-8
+git config --local diff.renameLimit 1
+git config --local diff.renames false
+```

docs/Если-что-то-пошло-не-так-FAQ.md

@@ -0,0 +1,54 @@
+## Расписание конвертации включено, но список версий пуст
+
+* Проверьте, что задана константа __"Путь к версиям платформы на сервере"__ и в настройках хранилища указана версия, соответствующая версии сервера хранилища конфигураций 1С:Предприятия.
+* Проверьте файл логов `log.txt` в каталоге выгрузок - там может быть написано что-то вразумительное.
+* Проверьте журнал регистрации базы 1С:ГитКонвертера - на наличие ошибок. Все мы - люди :)
+
+## Версии в списке версий хранилища в 1С:ГитКонвертере есть, но конкретная версия зависла (зациклилась) на этапе выгрузки конфигурации в xml
+
+* Можно посмотреть в лог пакетной операции для этой версии `/каталог выгрузки версий/ХХХ/log.txt` - пакетная операция Конфигуратора может сообщить что-то полезное
+* Если база версии "развалилась" в контекстном меню формы списка версий __сбросить состояние__  версии - она будет получена заново из хранилища.
+
+## Версии обрабатываются, но не коммитятся в Git
+
+* Проверьте, разрешен ли анонимный коммит в Git
+* Проверьте список версий хранилища - красным подсвечиваются версии, для авторов которых не указана контактная информация в регистре "Информация пользователей"
+* Нажмите кнопку "Выполнить коммиты" - для принудительного запуска коммитов обработанных версий в статусе "Метаданные загружены"
+
+## Коммиты не появляются на сервере Git
+
+* Адрес Git-сервера был добавлен после создания хранилища? Нужно нажать кнопку "Установить адрес репозитория Git" чтобы настройки появились в config-файле.
+* Откройте гит-клиент - проверьте, есть ли коммиты в локальном репозитории
+* Посмотрите лог коммита на Git-сервер, расположенные `/каталог выгрузки версий/gi_log_ver_XXX.txt`
+* Выполните команду `git push -u origin <branch name>` в консоли, чтобы проверить push вручную
+* Проверьте права доступа для пользователя от которого запущен сервер 1С - от его имени выполняется запуск скриптов `*.bat/*.sh` и глобальные настройки Git для этого пользователя.
+
+## В какой-то версии произошел сбой и файлы версии закомичены не полностью
+
+Т.е. в этой версии часть файлов или все были сначала удалены в репозитории, а следующая версия добавила файлы заново - сквозная история потерялась :(
+
+* Можно установить контроль минимального количества файлов в выгрузке, чтобы такого не случалось в будущем.
+* Т.к. это "односторонняя синхронизация" - то можно беспрепятственно откатить изменения `git reset --hard <commit>` на версию, до проблемной. 
+	* Далее в карточке хранилища установить поле "Версия в Git" на текущую в Git.
+	* Для всех версий, начиная с "проблемной" и последующих, выполнить команду в контекстном меню "Сбросить состояние"
+	* В каталоге `src` удалить файлы `DumpFilesIndex.txt` и `ConfigDumpInfo.xml` т.к. они не хранятся в репозитории и не откатились.
+	* Проверить что командные файлы `*.bat` (или `*.sh`) удалены для всех версий, начиная с проблемной.
+	* Если была установлена настройка Git-сервера, необходимо на сервере отключить защиту ветки (если есть такое) и выполнить `git push -u -f origin <branch name>` принудительную передачу данных с заменой репозитория на сервере.
+
+## В хранилище версия есть, а в Git она пропущена
+
+* Хранилище Конфигураций 1С:Предприятия позволяет сохранять новую версию без фактического изменения контента файлов, если меняется внутренняя версия объекта метаданных. Для Git в этом случае нечего коммитить.
+* Откройте файлы логов и убедитесь в том, что версия была обработана корректно
+
+## Не появляются новые версии из хранилища 1С
+
+* Убедитесь что версии действительно есть в Хранилище и у вас не установлены фильтры при просмотре списка версий в ГитКонвертере
+* Проверьте что написано в логе проекта - Конфигуратор может сообщать что-то полезное при получении отчета по хранилищу, который далее загружается в ИБ
+* Убедитесь что сервер 1С:Предприятия работает по-умолчанию на русском языке
+* Убедитесь, что "отчет по хранилищу" корректно загружается (см. "Журнал регистрации" на наличие ошибок. 
+
+## Проверка доступности версий EDT не выполняется из формы настроек хранилища в ГитКонвертере
+
+* Убедитесь что на сервере установлена единственная версия 1C:EDT (множественность версий EDT не поддерживается)
+* Выполните команду `ring edt platform-versions` убедитесь что версия 1С:Предприятия (она же версия хранилища 1С) указанная в форме настроек хранилища совпадает одной из списка, поддерживаемых EDT
+* Проверьте, что пользователь, от имени которого запущен сервер 1С:Предприятия имеет право выполнять команду `ring ...` - после установки EDT требуется рестарт сервера чтобы другому пользователю была доступна новая консольная команда Ринга

docs/Информация-пользователей.md

@@ -0,0 +1,5 @@
+Хранилище конфигураций "1С:Предприятия" использует для идентификации __Пользователя__, а в репозитории Git основным идентификатором является __email__ и имя пользователя. Для этих целей предназначен регистр сведений __Информация пользователей__, позволяющий указать соответствие пользователей хранилищ пользователям репозитория Git.
+
+Можно выполнять коммиты анонимно, с потерей информации об авторстве. Пользователь хранилища будет указан в дополнении к комментарию к каждой версии.
+
+Пользователи могут быть указаны общие для всех хранилищ или с уточнением по хранилищам.

docs/Как-это-работает.md

@@ -0,0 +1,58 @@
+Конфигурация 1С:ГитКонвертер разработана для того, чтобы:
+
+* выполнить первоначальную конвертацию хранилища конфигурации в репозиторий Git,
+* автоматически, по расписанию, обновлять ветку (например **master**) удалённого репозитория актуальным состоянием конфигурации из основного хранилища.
+
+Эта конфигурация может одновременно конвертировать и синхронизировать несколько хранилищ конфигурации и репозиториев. Для понимания принципов её работы рассмотрим пример с единственным хранилищем конфигурации, которое синхронизируется с удалённым репозиторием.
+
+[[images/001-58.png]]
+
+Компьютер, на котором установлена серверная информационная база с конфигурацией **1С:ГитКонвертер**, будем называть _сервер 1С:ГитКонвертера_. **1С:ГитКонвертер** получает данные из хранилища конфигурации, преобразует их в формат EDT, и фиксирует их в локальном репозитории, который находится на сервере 1С:ГитКонвертера. Затем он отправляет эти изменения в удалённый репозиторий Git, который находится на некотором компьютере, который назовём Git-сервер. Этот удалённый репозиторий и есть "хранилище проекта" для команды разработчиков (разработчик 1 и разработчик 2).
+
+
+**1С:ГитКонвертер** одну за другой, по очереди, читает версии конфигурации из хранилища и преобразует их. Процесс преобразования одной версии состоит из следующих этапов:
+
+[[images/002-44.png]]
+
+1. Используя интерфейс командной строки 1С:Предприятия 8 в **каталоге выгрузки версий** создаётся информационная база, в которую из хранилища получается очередная версия.
+1. Из информационной базы эта версия выгружается в XML файлы.
+1. Используя интерфейс командной строки **EDT**, XML выгрузка конфигурации преобразуется в фалы внутреннего формата EDT.
+1. Файлы внутреннего формата EDT помещаются в рабочий каталог проекта, который находится в **локальном каталоге Git**.
+1. Командами Git'а выполняется фиксация изменений в локальном репозитории и отправка их в удалённый репозиторий.
+
+Из этой схемы важно понять, что когда вы будете настраивать конвертацию хранилища в 1С:ГитКонвертере вам нужно будет указать два каталога:
+* Каталог выгрузки версий,
+* Локальный каталог Git.
+
+Для оптимальной производительности важно, чтобы оба этих каталога находились на одном логическом диске. Тогда будет использоваться перемещение версий средствами операционной системы. В противном случае будет выполняться копирование данных, что может занять дополнительное время.
+
+Также из этой схемы вы можете понять, что на сервере 1С:ГитКонвертера вам понадобится установить следующее программное обеспечение (подробнее об этом рассказывается в разделе Установка программного обеспечения на сервер 1С:ГитКонвертера):
+
+* Сервер и клиент 1С:Предприятия 8 для работы конфигурации 1С:ГитКонвертер,
+* Клиенты 1С:Предприятия 8 тех версий, на которых работают хранилища конфигураций, которые вы собираетесь конвертировать,
+* СУБД, поддерживаемую 1С:Предприятием 8, для хранения информационной базы 1С:ГитКонвертера,
+* EDT для преобразования XML файлов выгрузки конфигурации в формат EDT,
+* Git для фиксации изменений в локальном репозитории и отправки их в удалённый репозиторий.
+
+Конфигурация **1С:ГитКонвертер** обладает возможностями, которые вы можете использовать опционально, по желанию. Это такие возможности как:
+
+* Использование Git LFS - для хранения больших бинарных файлов вне репозитория; использование этой возможности позволяет ускорить операции с репозиторием.
+* Очереди выполнения - для балансировки нагрузки, создаваемой фоновыми заданиями, путём ограничения количества операций, выполняемых в каждой очереди.
+* Копии хранилища - для параллельной загрузки версий одного хранилища конфигурации.
+
+Перед выполнением дальнейших шагов желательно сначала ознакомиться с этими возможностями, потому что, например, решение об использовании **Git LFS** необходимо принять до начала работы с 1С:ГитКонвертером, основываясь на размере вашего хранилища конфигурации, количестве версий в нём и наличии конфигураций поставщиков. Другие возможности вы сможете задействовать и потом, уже в процессе работы.
+
+### Коммит в Git
+
+Для того, чтобы создать правильную историю изменений объектов в Git репозитории аналогичную Хранилищу 1С необходимо учитывать особенности двух систем:
+
+* Хранилище конфигураций 1С:Предприятия сохраняет изменения по объектам, идентификатором которого является внутренний UUID, недоступный для редактирования в Конфигураторе.
+* Репозиторий Git отслеживает изменения контента файлов при их перемещении.
+
+В случае, если объект в Конфигураторе был переименован - Хранилище 1С:Предприятия сохраняет новую версию того же объекта. Но если выгрузить конфигурацию в файлы - этот переименованный объект окажется в другом месте файловой иерархии, по сравнению с предыдущей версией. Если удалить объект, а потом создать с таким же именем - то история в Хранилище 1С будет новая для нового объекта.
+
+Так же, в выгрузке конфигурации 1С в xml присутствует множество файлов, очень похожих по контенту и именам (например ФормаСписка.xml), отличающихся только внутренним идентификатором (UUID).
+
+Поэтому, если в одной версии хранилища были удалены одни объекты (файлы), добавлены и/или переименованы другие - в Git нужно явно сообщить, что удалять, несмотря на похожие файлы в других каталогах, а так же то, какие файлы переименовываются. Таким образом, одна версия хранилища 1С может превращаться в 3 коммита: удаление файлов, переименование, и все остальные изменения контента в файлах и добавления файлов.
+
+Чтобы обеспечить корректное переименование истории объектов метаданных при переименовании/удалении их в хранилище конфигураций 1С:Предприятия создается файл индекса `DumpFilesIndex.txt` идентификаторов и файлов для каждой версии. На основе этого файла строится командный файл для выполнения коммита в Git `git_command_1.bat`

docs/Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools.md

@@ -0,0 +1,48 @@
+Выполнить конвертацию необходимо разово, чтобы "переключить" текущий формат с 1С:Предприятия на формат 1C:EDT.
+
+![Конвертация хранилища в формат 1C:EDT - Convert repository to 1C:EDT](../blob/master/ConvertToEDT.png?raw=true)
+
+__Внимание!__ 
+Конвертация в формат 1C:EDT необратима, поэтому последующая синхронизация с хранилищем 1С будет выполняться в формате 1C:EDT. Конечно, можно сделать "checkout" на коммит до конвертации и продолжить конвертацию в формате 1С:Предприятия в другой ветке, или откатить все изменения с помощью `git reset --hard <sha_commit>` и т.д. 
+Можно так же, в тестовых целях, создать копию элемента справочника "Хранилищ" и копию репозитория - создать ветку и конвертировать в формат 1C:EDT, оставляя возможность синхронизировать хранилище конфигураций с основной веткой Git в формате 1С:Предприятия.
+
+Структура каталогов выгрузки 1С:Предприятия и формата 1C:EDT похожи, но немного различаются. Для сохранения истории разработки в формате 1C:EDT запустите обработку __"Конвертация в формат EDT"__. Она выполняет перемещение файлов в соответствии с форматом 1C:EDT, выполняет коммит в гит, заменяет каталог `src` выгрузки 1С:Предприятия каталогом из 1C:EDT и выполняет второй коммит с изменением контента файлов.
+Стоит отметить, что содержание xml-файлов 1C:EDT и 1С:Предприятия в некоторых случаях различается существенно, поэтому построчное авторство в таких файлах сохранить не удастся. 
+Файлы текстов модулей `*.bsl` сохраняют историю полностью.
+
+1. Установите 1C:EDT 1.8 и выше на сервер.
+2. Если изначально каталог с именем проекта не был указан (ну забыли, не знали...) нужно заполнить **Имя проекта 1C:EDT** и будет выполнено перемещение `git mv ./src/... ./ИмяПроектаEDT/src/...` во время конвертации. Перемещение можно отключить, сняв галку **Выполнить перенос в каталог проекта**, если вы понимаете зачем это делаете.
+3. Если использовали __Git LFS__ - убедитесь что типы файлов, вынесенные в __LFS__, после конвертации с новыми именами/расширениями так же попадут в __LFS__.
+4. Выполните конвертацию репозитория с помощью обработки __Сервис -> Конвертация в формат EDT__, заполнив все обязательные поля.
+
+Если изначально был указан __"Каталог выгрузки в репозитории"__ соответствующий имени проекта, после конвертации можно открыть 1C:EDT в новом  Workspace и выполнить импорт проекта из Git: __File -> Import -> Git -> Projects from Git__ и убедиться в корректности конвертации.
+
+__Внимание!__ Рекомендуется читать документацию к 1C:EDT о настройках Git, работе с проектом, импорте и др.
+
+Соответствие имен файлов формата выгрузки 1С:Предприятия и формата 1C:EDT
+
+```
+Configuration.xml -> Configuration.mdo
+ClientApplicationInterface.xml -> ClientApplicationInterface.cai
+CommandInterface.xml -> CommandInterface.cmi
+HomePageWorkArea.xml -> HomePageWorkArea.hpwa
+MainSectionCommandInterface.xml -> MainSectionCommandInterface.cmi
+Form.xml -> Form.form
+Template.xml -> Template.bin     // BinaryData
+Template.xml -> Template.mxlx    // SpreadsheetDocument
+Template.xml -> Template.dcs     // DataCompositionSchema
+Template.xml -> Template.txt     // FileAwareTextDocument
+Template.xml -> Template.htmldoc // HtmlDocument
+Template.xml -> Template.addin   // AddIn
+Template.xml -> Template.scheme  // GraphicalScheme
+Template.xml -> Template.axdt    // ActiveDocument
+Template.xml -> Template.geos    // GeographicalSchema
+Template.xml -> Template.dcsat   // DataCompositionAppearanceTemplate
+Package.bin -> Package.xdto
+WSDefinition.xml -> WsDefinitions.wsdl
+Flowchart.xml -> Flowchart.scheme
+Rights.xml -> Rights.rights
+Schedule.xml -> Schedule.schedule
+```
+
+Другие файлы изменят имена не значительно, в соответствии с форматом 1C:EDT. Часть файлов (`Help.xml`, `Language.xml`, `Picture.xml`, `ФормаСписка.xml` и др.) будут удалены, т.к. контент файлов теперь хранится в составе других файлов.

docs/Копии-хранилища.md

@@ -0,0 +1,19 @@
+Копии хранилища позволяют ускорить получение версий из хранилища за счет распараллеливания этого процесса.
+
+[[images/001-60.png]]
+
+Копии хранилища могут понадобиться вам, например, при конвертации больших конфигураций. В этом случае получение версии из хранилища может занимать значительное количество времени, в течение которого ресурсы, занятые выгрузкой и конвертацией в формат EDT, будут простаивать.
+
+## Настройка
+
+Список копий хранилища доступен из формы хранилища конфигурации по ссылке **Копии хранилищ конфигурации**.
+
+Вы можете использовать в копиях тот же адрес серверного хранилища конфигурации, но с разными пользователями. Количество "копий" влияет на размер создаваемого глобального кэша версий на сервере хранилища конфигурации. Поэтому размер кэша необходимо настроить. Для этого откройте в Конфигураторе информационную базу, подключённую к этому хранилищу, и укажите размер глобального кэша (**Конфигурация → Хранилище конфигурации → Администрирование хранилища... → Прочие → Глобальный кэш версий конфигурации**).
+
+Выберите максимальный размер кэша в 1,5 - 2 раза больше, чем:
+
+_<размер одной версии в Мб>_ * _<количество копий хранилища>_
+
+Вы можете использовать в копиях адрес архивной копии хранилища, если в текущем хранилище конфигураций выполнялось сокращение версий. Тогда установите ограничение номеров версий в этой копии. Это позволит создать цельную историю изменений конфигурации в Git репозитории.
+
+Укажите **расписание получения версий** из этой копии. Если в копии указан адрес основного хранилища, вам необходимо в расписании учесть возможность работы разработчиков с хранилищем: запуски на получение выполнять с промежутками, обеспечивающими комфортную работу разработчиков.

docs/Максимум-скорости-на-историю.md

@@ -0,0 +1,80 @@
+## Цель
+
+Необходимо за максимально короткое время конвертировать историю огромную хранилища. 
+Предположим, что в оборудовании у нас нет ограничений или мы можем временно привлечь неограниченные ресурсы.
+
+## Настройка сервера хранилищ 1С
+
+Суть: создать множество копий хранилища чтобы параллелизировать получение версий. 
+
+* Подключаем на том же сервере (или на отдельном сервере в той же сети) - отдельный SSD-диск
+* Поднимаем 3 сервиса хранилищ конфигураций 1С на разных портах - настроенных на разные каталоги диска
+* Настраиваем [кэширование сервера хранилищ](Настройка-конвертации-хранилища-1С) в зависимости от количества потоков получения из хранилища
+* Копируем текущее состояние хранилища в 3 разных каталога - т.о. на одном SSD-диске 3 независимых копии хранилища. Следите за очередью к диску - может быть 3 шт. - это много, но крутые диски могут и больше!
+* Сервер хранилищ - многопоточный - но у него есть ограничение по памяти.
+
+## Настройка репозитория
+
+Суть: необходимо избегать копирование данных с диска на диск - поэтому располагаем хранилище и каталог выгрузок на одном диске
+
+* Размещаем каталог репозитория и каталог выгрузки на одном SSD-диске.
+* SSD-диск должен быть отдельным от того, на котором располагается сервер хранилищ 1С, если на одном сервере или сеть между серверами должна быть "прямая". 
+* В карточке настройки хранилища:
+  * В **Начальной версии** - указываем очень большое число, например `100000` - т.о. регламентное задание не будет пытаться выгрузить версии из хранилища и будет выполнять только сервисные действия (запуск коммитов, перезапуски итд).
+  * В **Версии окончания** укажите любое число - это ограничит рег.задание от получения отчета по хранилищу каждый раз - ведь нам нужно быстро догнать историю...
+* Укажите расписание запуска "Каждый день, каждые 60 секунд"
+
+
+## Настройка получения версий
+
+* Устанавливаем ограничения **"Количества подготавливаемых версий"** в настройках из расчета *Объем диска* / **Размер выгрузки** [см тут](Параметры-конвертации).
+* Создаем пользователей в каждой копии хранилища 1С с именами "Выгрузка1", "Выгрузка2"... "Выгрузка-N" - из расчета того сколько сможет выдержать параллельных потоков. Для простоты посчитать можно так: `4Гб / Размер cf версии`, например версия конфигурации 500Мб - значит можно начать с 8 потоков на один сервис хранилища, а дальше - следить за памятью сервиса.
+* Для каждого пользователя, для каждого сервиса хранилища 1С создаем настройку ["Копии хранилища"](Копии-хранилища) - в нашем примере 24 копии - для каждого настраиваем расписание запуска  **"каждый день, каждые 60 секунд"**
+* Укажите расписание запуска "Каждый день, каждые 60 секунд"
+
+## Настройка выгрузки в xml
+
+Суть: важно определиться - используем ли [выгрузку изменений](Параметры-конвертации) или нет.
+
+* Для **Выгрузки изменений** настраиваем для каждой очереди выгрузки рабочие диапазоны версий. 
+  * Первая очередь - от 1 версии до 50
+  * Вторая очередь - от 51 до 100
+  * Третья очередь - от 101 до 150
+  * Ограничением количества очередь - является размер диска, куда выгружаются версии
+* Не используем **Выгрузку изменений** - создаем столько очередь выгрузки сколько копий хранилищ - 24 шт.
+* Укажите расписание запуска очереди "Каждый день, каждые 60 секунд"
+
+## Настройка загрузки метаданных
+
+* Настраиваем количество очередей загрузки метаданных, в нашем примере - 10-20.
+* Для каждой очереди загрузки будет запущена конвертация в формат EDT - нам необходимо чтобы было доступно 8 ядер процессора на одну очередь
+* Укажите расписание запуска очереди "Каждый день, каждые 60 секунд"
+
+## Количество ядер CPU
+
+Суть: мы предположили, что у нас нет ограничений по оборудованию, поэтому посчитаем сколько нам необходимо.
+
+* 3-4 CPU на сервис хранилища
+* 24/2 = 12 CPU на получение из копий хранилищ
+* 1 CPU на очередь выгрузки
+* 80 CPU - на 10 очередей загрузки
+
+ИТОГО: 110-130 CPU
+
+## RAM для сервера
+
+* 3-4 Гб на сервис хранилища 1С, реально будет работать в диапазоне 2-3Гб.
+* 1Гб на очередь выгрузки
+* 4Гб на очередь загрузки (с учетом того, что конфигурация cf - всего 500Мб), на 10 очередей
+
+ИТОГО: 80-90 Гб RAM
+
+# РЕЗЮМЕ
+
+Конечно, в любом проекте есть ограничения. 
+Определите, какие ограничения у вас:
+* SSD (очередь к диску, размер)
+* CPU
+* RAM
+
+Рассчитайте максимальную загрузку сервера.

docs/Настройка-Linux.md

@@ -0,0 +1,8 @@
+
+## Включение UTF-8 и языка по умолчанию
+
+TODO
+
+## Настройка выполнения в пакетных команд Конфигуратора в X-сервере
+
+TODO

docs/Настройка-Windows.md

@@ -0,0 +1,25 @@
+## Длинные пути в Windows
+
+В некоторых версиях операционных системы Windows, по умолчанию, отключена работа с длинными путями. Длинный путь - это полный путь файла или папки, который превышает значение в 260 символов.
+
+Чтобы включить работу с длинными путями, необходимо:
+
+### Решения для тех у кого Windows 10 Pro и выше
+
+* Запустите консоль редактора локальной групповой политики, нажав Win+R и выполнив команду gpedit.msc
+* Перейдите в раздел редактора Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem -> NTFS (Конфигурация компьютера -> Административные шаблоны -> Система -> Файловая система -> NTFS)
+* Откройте политику Enable NTFS long paths
+* Включите политику, переведя ее в состояние Enabled
+* Сохраните изменения
+
+### Решения для тех у кого Windows 10 Home и ниже
+
+* Запустите редактор реестра regedit.exe
+* Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies
+* Создайте в данной ветке новый параметр типа Dword (32-bit) Value с именем LongPathsEnabled
+* Измените значение ключа на 1
+* Сохраните изменения
+
+## Поддержка кириллицы в ОС
+
+TODO...

docs/Настройка-базы-ГитКонвертера.md

@@ -0,0 +1,4 @@
+1. Разместите базу ГитКонвертера на сервере 1С. Работа в файловом режиме может быть использована только в демонстрационных целях.
+2. Заполните константу __"Путь к версиям платформы на сервере"__, где располагаются файлы Конфигуратора 1cv8(.exe) в формате: `C:\Program files (x86)\1cv8\%ВерсияПлатформы%\bin`
+где в параметр `%ВерсияПлатформы%` - будет подставлена текущая версия хранилища из настроек.
+4. Для ограничения производительности можно включить константу __"Использовать очереди выполнения"__ - количеством очередей можно балансировать нагрузку на сервер. (см. [Очереди выполнения](Очереди-выполнения))

docs/Настройка-конвертации-хранилища-1С.md

@@ -0,0 +1,5 @@
+1. Рекомендуется использовать сервер хранилищ конфигураций 1С.
+
+Для оптимальной работы сервера хранилищ настройте __Размер глобального кэша__ в "Администрировании" в 1,5-2 раза больше __количества__ параллельных потоков (если используются "копии хранилища") __получения версий * размер одной версии, Мб__.
+
+2. Создайте настройку конвертации хранилища и [настройте параметры](Параметры-конвертации).

docs/Настройка-сервера-1С.md

@@ -0,0 +1,44 @@
+## Журнал регистрации
+
+Для ИБ ГитКонвертера на сервере 1С рекомендуется настроить удаление, перенос в архив или полностью отключить журнал регистрации, т.к. интесивность событий в ИБ может быть очень высокой, а ценность истории ЖР за прошлые периоды - низкая.
+
+Для легкого удаления и архивирования ЖР можно переключить его формат на старый режим. Для этого необходимо в каталог журнала регистрации ИБ скопировать пустой файл с именем: __1Cv8.lgf__.
+Для больших проектов рекомендуется  выполнить такую настройку (удаление/бэкапирование файлов журнала регистрации).
+
+Так же рекомендуется переключить регистрацию событий - только ошибки. Для этого следует выбрать команду __Конфигуратор - Администрирование - Настройка журнала регистрации... = Регистрировать ошибки__ и в открывшемся диалоге установить минимально необходимую вам периодичностью.
+
+Пример файла `remove_journal.bat` для ОС Windows позволяющий удалить журнал старше 3 дней
+
+```bat
+@REM "Удаление журнала за 3 дня"
+forfiles /p "C:\Program Files\1cv8\srvinfo\reg_1541\13b55eb8-943e-410a-a5fd-25e27a3337c2\1Cv8Log" /m *.lgp /D -3 /c "cmd /c del @file"
+```
+
+в этой строке необходимо заменить идентификатор ИБ `13b55eb8-943e-410a-a5fd-25e27a3337c2` на ваш идентификатор базы 1С:ГитКонвертера на сервере 1С.
+
+## Чистка кэша баз данных 1С
+
+В процессе выполнения пакетных операций 1С:Предприятие создает временные данные (кэши) которые необходимы для оптимальной работы. Т.к. 1С:ГитКонвертер создает множество баз, "отрабатывает" их и более в них не нуждается (удаляет сами базы), то кэши необходимо чистить на сервере 1С:ГитКонвертера.
+
+Пример скрипта `remove_old_caches.bat` для Windows:
+
+```bat
+@REM "Удаление старых каталогов за 2 дня"
+forfiles /p "c:\Users\USR1CV8\AppData\Roaming\1C\1cv8" /S /D -2 /C "cmd /c IF @isdir == TRUE rd /S /Q @path"
+forfiles /p "c:\Users\USR1CV8\AppData\Local\1C\1cv8" /S /D -2 /C "cmd /c IF @isdir == TRUE rd /S /Q @path"
+```
+
+## Удаление файла списка версий `ibases.v8i`
+
+Для использования одного и того же кэша при разных запусках пакетных операций 1С:Предприятия Информационная База добавляется в список 1С. Со временем, если проект большой и количество версий в хранилище большое - список может очень вырости. Для сценария, когда 1С:ГитКонвертер приступает к конвертации версии сразу после ее внесения в Хранилище 1С т.е. "следит за разработкой", можно настроить чистку файла списка версий на сервере в период, когда все версии, добавленные за текущий день в Хранилище 1С, уже сконвертированы, например ночью, под утро:
+
+```bat
+@REM "Удаление файла списка версий"
+del /Q "c:\Users\USR1CV8\AppData\Roaming\1C\1CEStart\ibases.v8i"
+```
+
+Учтите, что **список версий** для каждого пользователя свой, т.о. можно удалять список только под тем пользователем, под которым запущен 1С сервер - в данном примере `USR1CV8`.
+
+## Перезагрузка сервера Windows
+
+В зависимости от интенсивности работы на сервере может потребоваться регулярная перезагрузка сервера Windows, например каждое утро перед началом рабочего дня разработчиков.

docs/Начальная-настройка.md

@@ -0,0 +1,41 @@
+## Сервер
+
+Вам необходим "сервер", на котором будет выполняться вся конвертация и обработка версий. Сервером может быть:
+
+* Простой компьютер разработчика, например, включаемый ночью для задач "конвертации"
+* Виртуальная машина в облаке
+* Выделенный физический сервер
+
+Производительность и параметры сервера нужно выбирать:
+1. Исходя из финансовых возможностей разработчика/компании
+2. С учетом размера проекта: количества версии истории, размера одной версии, времени за которое хочется конвертировать историю
+
+## Программное обеспечение
+
+1. Установите на сервере 1C:EDT версии 1.8.1 и выше. Убедитесь, что корректно установлены компоненты консольного режима 1C:EDT. Для этого в терминале (командной строке) выполните команду:
+
+ ```
+ ring edt platform-versions
+ ```
+
+ убедитесь что текущая версия хранилища поддерживается в 1C:EDT.
+ 
+Добавьте параметры вывода утилиты RING, в окружение системы переменную `RING_OPTS` со значением `-Dfile.encoding=UTF-8` для корретного вывода сообщений в общий файл лога конвертации версии.
+
+Для вывода всех сообщений RING и EDT на русском, установите в `RING_OPTS` значение:
+
+```
+-Dfile.encoding=UTF-8 -Dosgi.nl=ru
+```
+
+2. Установите сервер 1С:Предприятия 8, версии 8.3.12 и выше.
+
+Все команды по конвертации каждой версии будут выполняться в операционной системе от пользователя, от которого запущена служба сервера 1С. Убедитесь, что этому пользователю доступна команда `ring ...` - возможно, потребуется перезагрузка сервера после установки 1C:EDT.
+
+3. Установите на сервер Git версии 2.16 и выше. Например, отсюда: https://git-scm.com/downloads
+
+4. Установите на сервер Git LFS, если планируете использовать в вашем проекте. [См. раздел Git LFS](Git-LFS)
+
+5. Разместите на сервере 1С:Предприятия базу 1С:ГитКонверетера и [выполните начальную настройку базы](Настройка-базы-ГитКонвертера).
+
+6. Установите клиенты 1С:Предприятия (Конфигуратор) тех версий, на которых запущено хранилище конфигураций 1С. Конфигуратор будет выполнять большую часть работ по конвертации.

docs/Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища.md

@@ -0,0 +1,29 @@
+## Цель
+
+Нет желания, нет мощного оборудования или времени, чтобы конвертировать всю историю хранилища сначала. Необходимо начать разработку в EDT с текущего среза хранилища 1С (с определенной версии хранилища).
+
+## Настройка синхронизации, начиная с версии N
+
+1. Создаем настройку синхронизации в ГитКонверетре, [заполнив необходимые параметры](Параметры-конвертации)
+
+2. В поле **Начальная версия** укажите предыдущую версию хранилища, от той, которой необходимо начать `N-1`.
+
+3. В Конфигураторе выгрузите в файл "Отчет по версиям" хранилища и загрузите этот отчет в базу ГитКонвертера для текущей настройки синхронизации.
+
+4. Инициализируйте новый пустой репозиторий Git командой на форме настройки синхронизации хранилища. 
+
+   4.1. Выполните [дополнительную настройку Git](Git-LFS) по необходимости.
+
+5. В поле **Версия в Git** в настройке - укажите предыдущую версию, как в поле **Начальная версия** `N-1`.
+
+6. Перейдите в список **Версий хранилища** в панеле навигации формы - и все версии с начала и до указанной в поле **Версия в Git**, выделив в списке, пометьте как "Помещенные в хранилище" с помощью команды в контекстном меню списка.
+
+7. Запустите конвертацию, включив расписание синхронизации в форме настройки хранилища.
+
+## РЕЗЮМЕ
+
+Первой версией в Git репозитории будет следующая версия, после указанной настройках - версия `N`.
+
+Далее, синхронизация хранилища 1С и Git репозитория будет выполнятся в режиме "слежения" и не будет требовать много ресурсов, чтобы конвертировать всю историю.
+
+В такой схеме история изменений будет не полной, выполнять `git blame` (авторство строк кода) можно будет только для новых версий в хранилище.

docs/Обновление-с-версии-1.0.4.md

@@ -0,0 +1,2 @@
+**Внимание!**  Конвертация хранилища 1С в формат выгрузки xml 1С:Предприятия является устаревшей функциональностью и не доступна для новых настроек конвертации хранилища. 
+Текущие настройки синхронизации хранилища, конвертирующие в формат выгрузки xml 1С:Предприятия будут работать корректно, но рекомендуется выполнить разовую конвертацию в формат 1C:EDT и продолжить синхронизацию в этом формате.

docs/Оперативное-слежение-за-разработкой.md

@@ -0,0 +1,18 @@
+## Цель
+Необходимо как можно быстрее любое изменение в Хранилище 1С получать в Git-репозитории. Предположим, что у нас достаточно мощностей серверов чтобы обслужить работу разработчиков.
+
+## Настройки
+
+1. В настройках конвертации хранилища необходимо включить расписание конвертации очень интенсивное, например `Каждый рабочий день, с 9:00 по 19:00, повторять через 60 сек после завершения` - т.е. каждые 60 сек запрашивать новые версии. Но оцените нагрузку на сервер Хранилищ 1С - может быть для комфортной работы разработчиков лучше поставить `каждые 5 минут`.
+2. Установите `Первую версию` очень большую, например **100000**, и `Последнюю версию` установите равным 0 - такая настройка говорит регламентному заданию не выполнять получение версий (`*.cf`) из хранилища - т.к. это может быть затратно по времени, но запрашивать отчет о новых версиях - обычно, это быстрая операция.
+3. Создайте дополнительно настройку "Копии хранилища" в панели перехода:
+   * В поле `адреса хранилища` укажите такой же адрес, как основной настройке
+   * Создайте в Хранилище 1С второго пользователя с правами "только просмотр" (без возможности захвата объектов) и укажите этого пользователя в настройке "Копии хранилища". Пользователь должен отличаться от указанного в карточке настройки хранилища, т.к. авторизация одного пользователя в хранилище конкурентная.
+   * Установите расписание получения версий из Хранилища 1С `Каждый день, каждые 60 сек` при этом, подключение к хранилищу будет выполняться, только если новые версии были получены первым рег.заданием в п.1
+   * Создайте дополнительные настройки "Копий хранилищ" для получения нескольких версий параллельно. Оцените, выдержит ли ваш сервер Хранилищ 1С такую нагрузку при интенсивной работе разработчиков.
+
+Дополнительно, оцените, необходимо ли использовать **Очереди выполнения** для стабилизации нагрузки на сервере ГитКонвертера.
+
+## РЕЗЮМЕ
+
+Одно рег.задание следит только за появлением новых версий в хранилище и выполняет запуск фоновых заданий на обработку полученных версий, коммит и т.д. Другое(ие) регламентное задание в "Копии хранилища" выполняет "тяжелую работу" по получению версии (`*.cf`) из хранилища. Версии появляются в списке ГитКонвертера и конвертируются максимально быстро.

docs/Оптимизация-выгрузки-на-8.3.15.md

@@ -0,0 +1,8 @@
+Расширение позволяет для конвертации хранилищ 1С:Предприятия на версии **ниже 8.3.15** использовать оптимизированный алгоритм частичной выгрузки. При это не требуется настраивать [очереди выполнения](Очереди-выполнения) для частичной выгрузки.
+
+### Настройка
+
+1. Установите расширение в ИБ ГитКонвертера версии 1.0.6.2 или выше.
+2. Установите на сервер любую платформу 1С:Предприятия версии 8.3.15.х или выше.
+3. Укажете установленную версию в настройках в меню **Сервис -> Версия платформы 8.3.15 для оптимизации выгрузки** в формате `8.3.15.1489`.
+4. В карточке настройки конвертации хранилища установите флаг **Выгружать изменения**

docs/Очереди-выполнения.md

@@ -0,0 +1,23 @@
+Очереди позволяют ограничить количество операций, выполняемых фоновыми заданиями. Различается два вида операций: операции выгрузки конфигурации и операции загрузки метаданных.
+
+[[images/001-59.png]]
+
+Вы можете создавать очереди для каждого хранилища конфигурации, или общие, на всю базу 1С:ГитКонвертера.
+Необходимость использования очередей может возникнуть по двум причинам. 
+* Во-первых, это чрезмерная нагрузка на ресурсы сервера 1С:ГитКонвертера. Например, через какое-то время вы замечаете, что операции с диском или с оперативной памятью стали узким местом. Тогда с помощью очередей и запуска по расписанию вы можете ограничить количество операций, выполняемых фоновыми заданиями за один раз. 
+* Во-вторых, очереди понадобятся вам в том случае, если вы конвертируете большую конфигурацию, и для ускорения процесса хотите использовать не полную выгрузку конфигурации, а выгрузку только изменений - инкрементальную выгрузку конфигурации (такая возможность есть в платформе 1С:Предприятие 8 начиная с версии 8.3.10).
+
+## Настройка
+Чтобы очереди выполнения стали доступны, установите флажок **Сервис → Использовать очереди выполнения → Использовать очереди выполнения**.
+
+Список очередей выполнения доступен из формы любого хранилища конфигурации по ссылке Очереди выполнения.
+
+Если очередь общая, то выбор версий для обработки выполняется по дате версии. Это следует учитывать при конвертации проектов с длинной историей и более "молодых" проектов в одной базе 1С:ГитКонвертера.
+
+Если очередь для хранилища, то для каждого хранилища конфигурации вам необходимо создать как минимум две очереди:
+* Выгрузка конфигурации. Начиная с версии платформы 1С:Предприятие 8.3.10 вы можете использовать выгрузку изменений. Для этого необходимо выгружать версии строго последовательно, и поэтому не рекомендуется создавать более одной очереди на выгрузку.
+* Загрузка метаданных.
+
+Для каждой очереди вам следует указать **количество операций** (версий конфигурации), которые будут обрабатываться за один запуск. 
+
+Кроме этого вы можете указать диапазон версий, для разграничения "рабочей зоны" между разными очередями, а также расписание запуска.

docs/Параметры-конвертации.md

@@ -0,0 +1,34 @@
+## Основное
+
+* Укажите адрес хранилища. При использовании сервера хранилища рекомендуется настроить в администрировании хранилища параметр "Глобальный кэш версий конфигурации" чтобы количество кэшированных версий было больше параллельно получаемых версий.
+* Укажите версию платформы, рекомендуется использовать **8.3.12.1412** и выше. Она должна совпадать с версией сервера Хранилища конфигураций 1С и должна быть поддерживаема 1C:EDT (для проверки нажмите кнопку)
+* Укажите расписание запусков.
+* Укажите __Каталог выгрузки версий__, в котором будут создаваться временные каталоги с номерами версий и выгрузкой данных.
+* __Локальный каталог Git__ рекомендуется указывать на одном логическом диске с __Каталогом выгрузки версий__ - будет использовано перемещение версий возможностями ОС, иначе будет выполняться копирование.
+* __Каталог выгрузки в репозитории__ - относительный путь к каталогу выгрузки внутри репозитория. Необходимо указывать **имя проекта 1C:EDT**.
+* Установите флаг __Выполнять коммиты__ для выполнения коммитов. Отключение может быть необходимо с целью временно приостановить работу конвертера.
+
+
+Нажмите кнопку "Создать гит репозиторий" перед конвертацией - команда выполняет инициализацию репозитория и начальную настройку, специфичную для конфигураций 1С.
+
+## Использование Git сервера
+
+Если репозиторий планируется размещать на сервере Git - выполните [настройки авторизации в Git](Авторизация-в-сервере-Git)
+
+
+## Дополнительно
+
+* Укажите начальную версию в хранилище конфигураций, если текущее хранилище было обрезано и первая версия больше 1.
+* Если указана версия окончания - не будет выполняться запрос новых версий. Это может быть полезно, если требуется конвертировать сначала всю историю разработки.
+* Желательно ограничить количество подготавливаемых (выгружаемых) версий - рекомендуется установить значение исходя из __Размер базы с версией + Размер выгрузки в xml__ и размера жесткого диска.
+* Укажите __Минимальное количество метаданных__ - число файлов и каталогов выгрузки в xml - необходимо для контроля, что все файлы выгружены. Рекомендуется устанавливать количество, примерно 90-95% от количества файлов в текущей версии, чтобы учесть возможность удаления метаданных (т.е. сокращения количества файлов)
+* Разрешить помещать анонимно, если пользователь не найден в регистре [Информация пользователей](Информация-пользователей) - это может понадобиться, если автор хранилища версий единственный или авторство неуказанных пользователей не нужно.
+* Не рекомендуется устанавливать __Удаление конфигураций поставщиков__, если планируется загружать конфигурацию из файлов и обновлять конфигурации поставщиков. Опция позволяет оптимизировать размер хранилища Git и не хранить объемные файлы *.cf.
+* Установите __Удалять временные данные версии после коммита__ - рекомендуется на реальных проектах.
+* __Выгружать изменения__ - позволяет на Платформе 8.3.10 и выше выгружать только изменения. Доступно при использовании __"Очередей"__
+* Установите флаг __Обрабатывать все очереди__, если используются очереди в ИБ.
+
+## Наименование и описание
+
+* Можно указать дополнительную информацию в описании
+* Можно задать наименование настройки отличное от адреса хранилища в сворачиваемой группе "Описание"

docs/Расширения.md

@@ -0,0 +1,3 @@
+Расширения для кастомизации работы 1С:ГитКонвертера
+
+* [Версия Платформы Хранилища](Версия-Платформы-Хранилища) позволяет подклчаться к Хранилищу на версии, отличной от версии выгрузки.

docs/Символы-окончания-строк.md

@@ -0,0 +1,26 @@
+Если разработчики, работающие с репозиторием, используют разные операционные системы (Microsoft Windows, Linux, macOS), нужно настроить конвертацию символов окончания строк при чтении из репозитория. Следующие команды настраивают Git таким образом, что в рабочей копии разработчика будут использоваться "родные" для его операционной системы символы, а в репозитории всегда будет использоваться LF.
+
+Для операционной системы Microsoft Windows:
+
+```bash
+git config --global core.autocrlf true
+git config --global core.safecrlf true
+```
+
+Для операционных систем Linux и macOS:
+
+```bash
+git config --global core.autocrlf input
+git config --global core.safecrlf true
+```
+
+Подробнее о назначении этих параметров вы можете прочитать в документации Git на английском языке [git config core.safecrlf](http://git-scm.com/docs/git-config#git-config-coresafecrlf) и [git config core.autocrlf](http://git-scm.com/docs/git-config#git-config-coreautocrlf).
+
+**1С:ГитКонвертер** по умолчанию добавляет настройки окончания строк при инициализации репозитория кнопкой из формы настройки хранилища в локальные настройки репозитория:
+
+```bash
+git config --local core.autocrlf true
+git config --local core.safecrlf warn
+```
+
+Т.о. в репозиторий файлы попадут с окончаниями строк попадут как `LF`, выдавая предупреждения в лог, если в файле есть смешение `CRLF` и `LF`.

docs/Сквозная-история-в-ветках.md

@@ -0,0 +1,20 @@
+При использовании [Технологии разветвленной разработки конфигураций](https://its.1c.ru/db/v8std/content/2149184358/hdoc) или аналогичного процесса для ветвления создается отдельное хранилище на каждую ветку на основе определенного номера закладки в основном хранилище. История в таком хранилище начинается с 1 версии и не содержит истории основного Хранилища.
+
+## Цель
+Создание сквозной истории изменений для "хранилищ исправительных версий" в ветке Git репозитория. "Авторство кода" (`git blame`) будет сквозным для веток.
+
+## Настройки
+
+1. Создаем [настройку конвертации](https://github.com/1C-Company/GitConverter/wiki/Настройка-конвертации-хранилища-1С) для "исправительного" хранилища.
+   * Укажите `локальный каталог Git` репозитория отличающийся от основного хранилища
+   * Укажите `адрес репозитория на сервере Git` такой же как в настройке основного хранилища
+   * Укажите `имя ветки` например `release-1.2.1` имя ветки должно отличаться от имени, указанном в настройке конвертации основного хранилища.
+2. Скопируйте локальный каталог репозитория Git для основного хранилища в каталог, указанный в текущей настройке. Убедитесь предварительно что в текущий момент не выполняются коммиты в основном, что локальный репозиторий не находится в состоянии модификации.
+3. Найдите номер версии в основном хранилище на основе которого создано "исправительное" и скопируйте `хеш` коммита. 
+    * выполните команду создания ветки на основе хеша в каталоге с локальным репозиторием исправительного хранилища:
+    * `git checkout -b "release-1.2.1" c0c007b9dbe142a70e3bba57a6770a5e5ab3defb` - такая команда выполняет переключение состояния файлов на указанный хеш коммита и создает ветку с именем `release-1.2.1`
+    * Удалите файлы `/MyProject/src/ConfigDumpInfo.xml` и `/MyProject/src/DumpFilesIndex.txt` в скопированном репозитории - эти файлы не хранятся в репозитории и используются для расчета частичной выгрузки и переименований файлов.
+
+## РЕЗЮМЕ
+
+Если вы нашли правильную версию в основном хранилище, то первая версия в "исправительном" будет ей равна и не содержит фактических изменений в файлах. Конвертация первой версии не приведет к добавлению нового коммита. Далее конвертация из "исправительного" хранилища продолжается как обычно, но в другую ветку. "Авторство кода" Git рассчитывает с учетом всех изменений, сделанных в основном хранилище.

docs/Сращивание-истории-из-нескольких-хранилищ.md

@@ -0,0 +1,22 @@
+В течении длительного времени разработки Хранилище 1С "распухло" и было принято решение - создать новое хранилище на основе последней закладки в первом. В этом случае нет возможности просто добавить [копию хранилища](https://github.com/1C-Company/GitConverter/wiki/Копии-хранилища) с указанием диапазонов версий т.к. в каждом хранилище есть две разные версии с одинаковым номером: 1, 2, 3...
+
+## Цель
+Необходимо в Git репозитории получить сквозную историю проекта из двух (или более) Хранилищ 1С, созданных с 1 первой версии (закладки в хранилище).
+
+## Настройки
+
+1. У нас уже существует настройка конвертации для первого (самого исходного) Хранилища 1С.
+2. Добавляем настройку конвертации второго (и далее) Хранилища 1С
+    * В поле `адрес хранилища` укажите адрес второго хранилища на сервере хранилищ
+    * Укажите `каталог выгрузки версий` отличающийся от исходного
+    * Укажите `каталог репозитория` тот же самый, который указан в первой настройке хранилища
+    * Укажите `имя ветки` совпадающее с именем в первой настройке 
+    * Временно снимите флажок `Выполнять коммиты` - до тех пор, пока не закончится конвертация из первого хранилища.
+    * Все остальные настройки могут быть настроены по аналогии или скопированы из первого.
+3. Если второе хранилище было создано на основе версии, например, `№49538` из первого хранилища, но пока создавали разработчики добавили новые закладки `49539` `49540` `49541`... в исходное (первое) хранилище, то необходимо в первой настройке конвертации указать версию ограничения по которую необходимо выполнять коммиты = `49538`
+
+## РЕЗЮМЕ
+
+Коммиты в репозиторий необходимо выполнять последовательно. Поэтому сначала выполняем и завершаем конвертацию первого хранилища, потом продолжаем в этот же локальный репозиторий конвертировать из второго Хранилища 1С, установив флаг `Выполнять коммиты` во второй настройке и, сняв этот флаг в первой. **Важно**, чтобы имя ветки совпадало с указанным в первой настройке и адрес репозитория на Git сервере, если указан. 
+
+Ближе к окончанию конвертации первого хранилища, можно запустить конвертацию и подготовку версий из второго хранилища, но сняв галочку `Выполнять коммиты` - это позволит пре-подготовить версии к моменту "переключения" хранилищ и быстро закоммитить. Количество подготавливаемых версий зависит от размера одной версии `*.cf`, базы, выгрузки и т.д. и объема вашего HDD/SSD диска.

docs/Сценарии-применения.md

@@ -0,0 +1,5 @@
+* [Начать работу в EDT, не конвертируя все предыдущие версии хранилища](Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища)
+* [Максимум скорости на историю](Максимум-скорости-на-историю)
+* [Оперативное слежение за разработкой](Оперативное-слежение-за-разработкой)
+* [Сращивание истории из нескольких хранилищ](Сращивание-истории-из-нескольких-хранилищ)
+* [Сквозная история в ветках](Сквозная-история-в-ветках)