Версионирование

Определение

Версионирование (от англ. versioning) — система обозначения последовательных состояний файлов в процессе работы над проектом

Версии могут появляться у проектов After Effects, 3D-сцен, аниматиков, монтажей, секвенций, промежуточных рендеров, MOV-, AVI-файлов и других материалов, которые проходят через несколько итераций до финала.

Зачем это нужно?

Версионирование помогает дизайнеру, арт-директору, проджекту и заказчику понимать, какой именно материал сейчас является предметом работы или обсуждения.

При понятной системе версий можно быстро определить:

• что изменилось существенно, а что было небольшой корректировкой;
• какой рабочий файл сейчас актуален;
• к какой итерации относится комментарий;
• какой материал отправлялся заказчику;
• к какому состоянию проекта нужно вернуться, если новое решение не сработало.

Пока в папке три файла, проблема почти незаметна. Когда их становится тридцать, final, final2, final_new и final_new_last уже приходится открывать по очереди, чтобы выяснить, какой из них нужен.

Какую систему мы используем

Единого обязательного стандарта именования версий в motion production нет.

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

Если у команды уже есть своя понятная система и она работает, менять её необязательно. Если такой системы нет, эту схему можно использовать как отправную точку.

Новое состояние работы — новая версия; небольшая правка внутри этого состояния — корректировка текущей версии.

Рабочие файлы

Для рабочих файлов важно видеть историю развития материала. Например:
history_V01.aep
history_V02.aep
history_V03.aep

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

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

В таком случае появляется следующая версия:
history_V02.aep

Номер версии фиксирует изменение состояния работы. Количество промежуточных действий здесь значения не имеет.

Небольшие корректировки

Не каждая правка требует увеличивать номер версии. Если после V02 обнаружилась опечатка, изменилось название города, немного сдвинулась стрелка, исправился текстовый слой или был устранён небольшой скачок кадра, это можно считать корректировкой существующей версии.

Для таких изменений мы используем +:
history_V02+.aep

Следующая небольшая корректировка:
history_V02++.aep

Если после этого материал снова существенно перерабатывается:
history_V03.aep

Получается такая последовательность:
V01 → V01+ → V02 → V02+ → V02++ → V03

V обозначает новую содержательную итерацию.
+ обозначает небольшую корректировку внутри неё.

Это не технический стандарт и не обязательная для всех система. Важно, чтобы внутри команды все одинаково понимали, где заканчивается корректировка и начинается следующая версия. Жёсткой границы здесь всё равно не получится. Исправление двух надписей не обязано автоматически превращать V02 в V03. Смотрим на масштаб изменения самого материала. Если работа по существу осталась той же, мы считаем это корректировкой. Если изменилось её состояние — появляется следующая версия.

Почему не нужно делать новую версию после каждой мелкой правки

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

Система V02, V02+, V02++, V03 позволяет сразу увидеть, где произошла следующая итерация работы, а где внутри неё просто внесли исправления.

Файлы для заказчика

С файлами, которые передаются заказчику, задача другая. Все эти V04, V04+, V05 и V05++ в первую очередь нужны команде внутри производства. В нашей практике внутренний номер версии в файл для заказчика обычно не переносится. Для согласований мы используем дату передачи:
history_2026-09-24.mov

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

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

Дата в рабочих версиях

Дата может быть полезна и внутри производства, особенно если проект длинный, согласований много или к одной версии постепенно накапливаются небольшие корректировки.

Например:
history_V03+_2026-09-24.aep

Мы рекомендуем формат:
YYYY-MM-DD

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

Но дата нужна далеко не в каждом проекте. Если V01, V02, V03 уже позволяют команде быстро ориентироваться в истории работы, дополнительная информация только усложнит название.

Что должно быть в названии файла

Хорошее имя позволяет понять, что находится внутри, ещё до открытия файла.

Например:
museum_map_V03.aep

понятнее, чем:
final_new_2.aep

Во втором случае через месяц почти наверняка придётся открыть файл, чтобы вспомнить, что именно там лежит. В первом значительная часть контекста уже есть в названии.

По имени желательно понимать:

• к какому проекту или материалу относится файл;
• что именно находится внутри;
• какая это рабочая версия, если версия имеет значение;
• дату, если она нужна для согласований или длинной истории проекта.

При этом не стоит превращать имя файла в производственную документацию. Чем сложнее правило, тем выше вероятность, что через некоторое время команда перестанет ему следовать.

Небольшое замечание о латинице

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