1С хранилище: как откатить объект к предыдущей версии

Хранилище конфигурации в 1С ведёт историю изменений всех объектов: каждая помещённая версия фиксируется с номером, автором и комментарием. Благодаря этому любую ошибочную доработку можно отменить — вернуть объект к состоянию на нужную версию хранилища. Откат возможен как для отдельного объекта (справочника, документа, модуля), так и для конфигурации целиком.

Важно понимать: в хранилище нет кнопки «отменить версию». Откат делается через получение старой версии объекта и повторное помещение его как новой версии. История при этом не перезаписывается — ошибочная версия остаётся в журнале, а поверх неё создаётся новая, с восстановленным содержимым. Это безопасный механизм, но он требует аккуратности при работе в команде.

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

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

Каждое помещение объектов в хранилище создаёт новую версию конфигурации с порядковым номером. Версия хранится целиком: платформа сохраняет слепок конфигурации на момент помещения. Поэтому «откат объекта» фактически означает: взять состояние объекта из старой версии и сделать его актуальным.

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

Принципиальный момент: откат не удаляет версии из истории. Если объект испорчен в версии 150, а вы восстановили состояние версии 145, то в хранилище появится версия 151, в которой объект совпадает с версией 145. Вся цепочка изменений остаётся доступной для просмотра и повторного отката.

Откат отдельного объекта через историю объекта

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

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

После этого объект в вашей конфигурации отличается от актуальной версии хранилища. Чтобы зафиксировать откат, захватите объект в хранилище (если он ещё не захвачен) и поместите его с комментарием вида «Откат к версии N: причина». Осмысленный комментарий критически важен — без него коллеги не поймут, почему их доработки исчезли.

1. 1
   Сохраните свои незавершённые доработки по этому объекту отдельно (выгрузка в файл, копия модуля).
2. 2
   Откройте историю объекта в хранилище и найдите версию с корректным состоянием.
3. 3
   Получите выбранную версию в конфигурацию.
4. 4
   Проверьте объект: откройте модуль, форму, сравните с ожиданиями.
5. 5
   Захватите объект и поместите его в хранилище с понятным комментарием об откате.
6. 6
   Обновите конфигурацию базы данных и проверьте работу функционала.

Откат всей конфигурации к версии хранилища

Если испорчено много объектов или нужно вернуться к состоянию на конкретную дату, проще откатить конфигурацию целиком. Откройте окно хранилища, перейдите на закладку «Версии» (история хранилища), выберите нужную версию и выполните «Загрузить конфигурацию из хранилища» с указанием номера версии — либо используйте команду получения версии из истории.

Платформа загрузит конфигурацию выбранной версии полностью, заменив текущую. Все объекты, изменённые после этой версии, вернутся к старому состоянию. Затем конфигурацию нужно поместить обратно в хранилище как новую версию — для этого потребуется захватить изменённые объекты (при массовом откате удобно захватывать корень конфигурации, если это разрешено политикой команды).

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

Откат через сравнение и объединение с файлом конфигурации

Альтернативный путь — выгрузить нужную версию в файл .cf и затем через «Сравнить, объединить с конфигурацией из файла» выборочно перенести изменения. Файл версии можно получить из истории хранилища (выгрузка версии) или взять из резервной копии релиза.

Преимущество способа — гранулярный контроль: в окне сравнения видно, какие именно объекты и свойства изменятся, и можно отметить только нужные. Это удобно, когда откатить надо часть изменений внутри одного объекта, например вернуть старый текст модуля, но оставить новый реквизит.

Недостаток — трудоёмкость и риск пропустить связанные изменения. Если старая версия объекта ссылается на реквизит или метод, который в новых версиях удалён или переименован, после объединения конфигурация может не пройти проверку. Всегда выполняйте полную проверку конфигурации после такого отката.

Сравнение способов отката

История объекта

Быстрый точечный откат одного объекта. Ограничение: откатывает объект целиком, без выбора отдельных изменений.

Загрузка версии хранилища

Подходит для отката всей конфигурации к дате или релизу. Ограничение: затирает все более поздние доработки.

Сравнение с файлом .cf

Гибкий выборочный перенос изменений, в том числе частичный откат внутри объекта. Ограничение: требует аккуратности и полной проверки конфигурации после объединения.

Ограничения, захваты и работа в команде

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

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

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

Проверка результата после отката

После помещения откаченного объекта убедитесь, что результат соответствует ожиданиям. Откройте историю объекта ещё раз: последняя версия должна быть вашей, с комментарием об откате. Сравните её с целевой старой версией через команду сравнения версий — различий быть не должно (если откат был полным).

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

Контрольные точки

Как проверить результат отката

Сравнение новой версии с целевой старой

Норма

Различий нет или есть только осознанно оставленные изменения

Тревожный признак

Объект отличается от целевой версии — откат выполнен не полностью или не из той версии

Проверка конфигурации

Норма

Нет ошибок о не найденных объектах и методах

Тревожный признак

Ошибки ссылочной целостности — старая версия ссылается на удалённые объекты

Работа функционала в тестовой базе

Норма

Сценарии выполняются как в целевой версии

Тревожный признак

Ошибки времени выполнения в местах использования объекта

FAQ: частые вопросы об откате объектов в хранилище 1С

Можно ли удалить ошибочную версию из истории хранилища?

Нет, штатного способа удалить отдельную версию нет — история хранилища не редактируется. Откат выполняется созданием новой версии со старым содержимым. Радикальный вариант — создание нового хранилища из выгруженной конфигурации нужной версии, но при этом теряется вся история, поэтому так делают только в исключительных случаях.

Что будет, если откатываемый объект захвачен другим разработчиком?

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

Как откатить только часть изменений внутри одного объекта?

Через историю объекта это невозможно — восстанавливается объект целиком. Используйте выгрузку нужной версии в файл .cf и «Сравнить, объединить с конфигурацией из файла»: в окне сравнения отметьте только те изменения, которые нужно вернуть. Для модулей альтернатива — скопировать нужный фрагмент кода из старой версии вручную через сравнение текстов.

Откатится ли конфигурация базы данных автоматически после отката в хранилище?

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

Как узнать, к какой версии откатывать объект?

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

Можно ли откатить объект, если хранилище недоступно?

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