Как вести версии файлов и не путаться в final, final2 и final-new

Файлы с названиями final.psd, final2.psd, final-new.psd и final-real-last.psd знакомы практически каждому, кто регулярно работает с проектами.

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

Используйте номер версии

Вместо постоянного переименования файла в «новый» или «последний» используйте последовательный номер.

Например:

landing-v01.fig

landing-v02.fig

landing-v03.fig

Так сразу видно порядок изменений.

Используйте одинаковый формат номера

Лучше заранее выбрать один формат и придерживаться его.

Например, v01, v02, v03 удобнее, чем случайное сочетание version2, new3 и latest.

Особенно это заметно в проектах с десятками итераций.

Когда полезно добавлять дату

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

Например:

report-2026-09-21.xlsx

contract-2026-09-21.pdf

photos-2026-09-21.zip

Формат год-месяц-день хорошо сортируется по имени.

Не используйте final до утверждения

Если клиент ещё может прислать правки, файл фактически не является финальным.

Лучше продолжать использовать номер версии.

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

Например:

logo-v06-approved.ai

или

presentation-v04-final.pdf

Храните старые версии отдельно

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

Создайте внутри проекта папку Архив или Old versions.

После появления новой утверждённой версии старые материалы можно переносить туда.

Это сохраняет историю работы, но не мешает видеть актуальные документы.

Не перезаписывайте важный файл вслепую

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

Это особенно важно перед крупными правками, после согласования этапа или перед передачей проекта другому специалисту.

Версия должна означать одно и то же для всей команды

Если один сотрудник считает v2 вторым черновиком, а другой — вторым утверждённым вариантом, путаница всё равно останется.

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

Например: любое заметное изменение создаёт следующую версию, а отметка approved появляется только после согласования.

Версии особенно важны дизайнерам

Макеты часто проходят несколько кругов правок.

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

Подробнее: облачное хранилище для дизайнеров.

То же правило полезно фрилансерам

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

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

Подробнее: облачное хранилище для фрилансеров.

Перед передачей клиенту создайте отдельный результат

Не отправляйте клиенту папку, где одновременно находятся v01, v02, v03 и десяток временных файлов.

Поместите утверждённый результат отдельно.

Перед отправкой можно использовать наш чек-лист передачи файлов клиенту.

Как связать версии со структурой папок

Удобная схема выглядит так:

Исходники → актуальные рабочие материалы

Рабочие файлы → текущие версии

Результат → утверждённый вариант

Архив → предыдущие версии

Подробнее об организации проекта: как организовать структуру папок проекта.

Для дизайнерских проектов смотрите также как хранить макеты и передавать файлы клиентам.

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

Итог

Для нормального контроля версий не нужна сложная система.

Используйте последовательные номера, при необходимости добавляйте дату, переносите старые варианты в архив и не называйте файл final, пока работа действительно не завершена.