Возврат к прошлой версии хранилища 1С 8.3: локальная отмена, откат версии и восстановление объектов

Откатить хранилище конфигурации 1С назад проще всего «вперёд»: откройте Конфигурация → Хранилище конфигурации → История хранилища, сохраните нужную версию в файл .cf, захватите объекты, объедините текущую конфигурацию с этим файлом и поместите результат как новую версию. История при этом не теряется, а содержимое хранилища становится таким, каким было в выбранной версии.

Если правки ещё не помещены в хранилище, всё ещё проще: достаточно отменить захват и получить объекты из хранилища заново. Убрать версию из истории физически можно только одним путём — восстановить каталог хранилища из резервной копии.

Как хранилище хранит версии и что значит «откат»

Хранилище конфигурации — это отдельная база (в файловом варианте — каталог с файлом 1cv8ddb.1CD и служебными папками). Каждое помещение изменений создаёт новую версию с номером, автором, датой и комментарием.

У каждого разработчика есть три слоя конфигурации, и путаница между ними — главная причина неудачных откатов:

• 📦 Хранилище — общая история версий, источник правды для команды.
• 🛠 Основная конфигурация разработчика — то, что открыто в дереве конфигуратора. Сюда попадают полученные из хранилища объекты и ваши правки захваченных объектов.
• 🗄 Конфигурация базы данных — то, с чем реально работают пользователи. Она меняется только после команды Конфигурация → Обновить конфигурацию базы данных (F7).

Отсюда практический вывод: откат в хранилище сам по себе ничего не меняет в рабочей базе. Пока вы не получили объекты и не обновили конфигурацию БД, пользователи работают на прежней версии.

Три сценария, которые обычно называют откатом:

Что проверить до начала отката

Откат хранилища затрагивает всю команду, поэтому начните с подготовки.

1. Сделайте копию каталога хранилища. Для файлового хранилища — скопируйте папку целиком, когда никто не помещает изменения. Для сервера хранилища (crserver) — согласуйте окно и копируйте каталог при остановленной службе.
2. Выгрузите свою базу в .dt. Администрирование → Выгрузить информационную базу. Это страховка на случай, если после отката понадобится обновить конфигурацию БД.
3. Проверьте права пользователя хранилища. Для захвата объектов нужно право захвата, для работы с пользователями и копиями — административные функции. Права смотрят в Конфигурация → Хранилище конфигурации → Администрирование хранилища.
4. Предупредите коллег. Пусть поместят или отменят свои захваты. Если в хранилище висит чужой захват нужного объекта, вы его не перехватите без отмены захвата администратором.
5. Найдите точный номер версии, к которой возвращаетесь. Ориентируйтесь на дату и комментарий в истории, а не на память.

💡 Если у команды принято ставить метки (Установить метку в окне истории) перед выпуском релиза, нужную версию найти проще: ищите метку, а не дату.

Отмена незавершённых изменений у себя в конфигураторе

Это локальный откат: вы что-то поменяли в захваченных объектах, результат не нравится, в хранилище правки ещё не попали.

1. В дереве конфигурации выделите захваченные объекты (отмечены красной галочкой). Можно выделить корень конфигурации — команда обработает всё, что захвачено вами.
2. Выполните Конфигурация → Хранилище конфигурации → Отменить захват или ту же команду из контекстного меню объекта: Хранилище → Отменить захват.
3. В окне отмены захвата оставьте включённым получение объектов из хранилища. Тогда локальные правки заменятся версией из хранилища.
4. Если ранее вы уже обновили конфигурацию БД с неудачными правками, выполните F7 ещё раз, чтобы рабочая база вернулась к версии хранилища.

Когда объект не захватывали, а правили «мимо» хранилища (например, при отключении от него), отмена захвата не поможет. В этом случае выделите объект и выполните Получить из хранилища — платформа предложит заменить локальную версию.

Возврат хранилища к прошлой версии

Неудачная версия уже помещена, коллеги её получили. Задача — сделать так, чтобы следующая версия хранилища совпадала с выбранной старой.

Шаг 1. Сохраните нужную версию в файл

1. Откройте Конфигурация → Хранилище конфигурации → История хранилища.
2. Нажмите «ОК» в окне отбора (или задайте период, если версий тысячи).
3. Выделите версию, к которой возвращаетесь, и выполните команду сохранения версии в файл. Получится обычный .cf.

То же можно сделать из командной строки, если конфигуратор с хранилищем открывается медленно:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F "D:\Bases\Dev" ^
 /ConfigurationRepositoryF "\\srv\Repo\Buh" ^
 /ConfigurationRepositoryN "Иванов" /ConfigurationRepositoryP "пароль" ^
 /ConfigurationRepositoryDumpCfg "D:\Temp\v152.cf" -v 152 ^
 /Out "D:\Temp\dump.log"

Номер платформы в пути замените на свой, -v 152 — номер версии из истории.

Шаг 2. Захватите объекты

Выделите корень конфигурации и выполните Захватить в хранилище с флажком рекурсивного захвата. Если откатываете только часть доработки, захватите лишь затронутые подсистемы и объекты — меньше конфликтов с коллегами.

Шаг 3. Объедините с версией из файла

1. Конфигурация → Сравнить, объединить с конфигурацией из файла — укажите сохранённый .cf.
2. В окне сравнения включите отбор «показывать только отличия».
3. Отметьте флажками объекты, которые возвращаются к старому виду. Режим объединения — «взять из файла».
4. Объекты, которые появились после выбранной версии, платформа покажет как отсутствующие в файле. Если их тоже надо убрать, отметьте удаление.
5. Нажмите Выполнить и проверьте конфигурацию: Конфигурация → Проверка конфигурации.

Шаг 4. Поместите откат как новую версию

Выполните Поместить в хранилище. В комментарии напишите явно: «Откат к версии 152: отмена доработки по заказу 45». Через полгода такой комментарий сэкономит расследование.

После этого все разработчики получают объекты из хранилища, а ответственный обновляет рабочую базу.

Удаление версий из истории: только через копию хранилища

Иногда нужно, чтобы неудачных версий не было совсем: в хранилище по ошибке поместили конфигурацию с чужими доработками, огромные макеты, или хранилище сломалось после сбоя.

Точечно вырезать версию из середины истории в интерфейсе хранилища не получится. Рабочий путь один — подменить каталог хранилища копией.

1. Попросите всех разработчиков отключиться от хранилища: Конфигурация → Хранилище конфигурации → Отключиться от хранилища.
2. Остановите службу сервера хранилища, если используется crserver. Все подключения к хранилищу оборвутся — делайте это в согласованное окно.
3. Переименуйте текущий каталог хранилища, но не удаляйте его.
4. Положите на его место копию, сделанную до неудачной версии. Запустите службу.
5. Каждый разработчик подключается к хранилищу заново: Конфигурация → Хранилище конфигурации → Подключиться к хранилищу. Платформа предложит заменить основную конфигурацию версией из хранилища.

Чем это грозит:

• 🔻 все версии после даты копии пропадут, включая полезные;
• 🔻 у разработчиков, которые успели получить новые версии, основная конфигурация окажется «новее» хранилища — им нужно заново подключиться и принять версию хранилища;
• 🔻 захваты, сделанные после копии, исчезнут.

Ценные правки из «пропавших» версий заранее сохраните в .cf из переименованного каталога: подключитесь к нему отдельной базой и выгрузите нужную версию.

Выборочное восстановление объекта из истории

Самый частый случай на практике: сломали один модуль, форму или макет, а остальное трогать нельзя.

Через историю объекта

1. В дереве конфигурации найдите объект, например Документы → РеализацияТоваровУслуг.
2. Контекстное меню → Хранилище → История. Откроется история только этого объекта.
3. Выделите версию и сравните её с текущей. Видно, какие модули, формы и реквизиты поменялись.
4. Убедитесь, что нашли версию до поломки, и сохраните её в файл .cf.

Через объединение

1. Захватите объект в хранилище.
2. Сравнить, объединить с конфигурацией из файла — укажите сохранённый .cf.
3. Снимите все флажки и оставьте только нужный объект. Для модуля можно спуститься до уровня процедур и взять из файла только испорченную.
4. Выполнить, проверить, поместить в хранилище с комментарием.

Восстановить удалённый объект метаданных тем же объединением можно: он вернётся из файла вместе с внутренним идентификатором. Ссылки в данных, которые указывали на него до удаления, при этом не воскреснут.

Откат, когда разработка идёт параллельно

Ветвления в привычном смысле у хранилища 1С нет: история одна, линейная. Команды обходят это двумя способами, и от способа зависит, как откатываться.

Отдельное хранилище под крупную доработку. Основное хранилище — «стабильная ветка», второе — разработка. Перенос делают объединением: сохраняют версию из хранилища разработки в .cf и объединяют с основной конфигурацией. Откат в такой схеме прост — основное хранилище просто не получает неудачную версию.

Метки на версиях. Перед выпуском ставят метку «Релиз 2.4». Если релиз неудачный, откатываются к версии с меткой по схеме из раздела про возврат к прошлой версии.

Если в одной версии смешались ваша неудачная правка и нужная правка коллеги, откатывайте по объектам, а не всей конфигурацией. При объединении проверяйте модули построчно: в окне сравнения модуля видно, какие процедуры отличаются, и можно взять только свои.

Для расширений конфигурации подход тот же: если расширение подключено к своему хранилищу, у него своя история, и откатывается оно отдельно от основной конфигурации.

💡 Команды, которые часто откатываются, со временем переходят на 1С:EDT с Git: там ветки и git revert решают задачу без ручного объединения. Для небольшой команды хватает и хранилища с дисциплиной меток.

На чём спотыкаются при откате хранилища

Отдельно про рабочую базу. Обновление конфигурации БД после отката может потребовать монопольного доступа, если меняется структура таблиц. Пользователей придётся отключить — планируйте это на нерабочее время.

Частые вопросы