Когда Ctrl-Z не хватает
Ситуация. Вы готовите презентацию, пишете отчёт или код, дизайните обложку, в общем, работаете над проектом не одного дня. В какой-то момент требуется доработка: заказчик попросил, пользователь обнаружил баг или начальнику что-то не понравилось. Вы вносите правки, отправляете на проверку, и получаете ответ наподобие «это оставь, а то верни, как было».
Как откатить часть изменений?
Решение 1. Завести директорию для версий.
- Заводите директорию под архив предыдущих версий.
- Когда правки накопились, копируете текущую версию в архив и даёте ей номер.
Решение 1. Директория с версиями файла.
Решение 2. Особенное имя для текущей версии.
- Одна директория под все версии, включая текущую.
- Имя текущей версии начинаете с нижнего подчёркивания («_презентация.pptx»).
Так она сортируется первой в списке файлов.
- Если файловый проводник сортирует файлы иначе, начните имя текущей версии по-другом, например, с «A» или «0».
- Когда правки накопились, копируете текущую версию и переименовываете подобно прошлым.
Решение 2. Особенное имя для текущей версии, чтобы она всегда была под рукой.
Решение 3. Символьная ссылка.
Вы действуете как в Решении 2, но поддерживаете ссылку на текущую версию. Особенно удобно при работе из командной оболочки.
Решение 3. Символьная ссылка на текущую версию.
Дальнейшие усовершенстовования
Решение 4. Система контроля версий.
Погромисты придумали автоматический инструмент, называемый «системой контроля версий». Это программа, которая следит за изменениями в файлах проекта и позволяет их сохранять в историю. Затем вы можете просматривать историю, отслеживать изменения и автоматически получать их список в формате «было-стало». Вообще, такая система незаменима для проектов, над которыми работают несколько людей.
Самая популярная система контроля версий сейчас (2025) это Git. Но некоторые проекты используют Subversion и Mercurial. Если вы не работаете в консоли, посмотрите на оконные морды для гита, они удобны. Из оконных морд я пользовался только Sublime Merge.
Ещё я бы отметил систему Fossil. В ней, помимо контроля версий, встроена возможность развернуть свой мини-гитхаб с форумом, вики и прочим.
Семантическое версионирование
Версионирование это набор принципов, по которым вы решаете «что такое версия, а что нет». А ещё версионирование решает, как версии продукта именовать. В идеале, версия файла вам должна сообщить масштаб изменений, и стоит ли она вашего внимания. Простейший пример — номер издания книги.
Пожалуй, самый компактный и гуманистический набор правил это semantic versioning. Он создавался под программное обеспечение, но идеи хороши и для других продуктов. Я бы сформулировал единственный принцип так.
Изменения в продукте бывают разных категорий и значимости. Название версии продукта должно это отражать.
Версионирование необходимо более-менее крупным проектам. А при разработке программного обеспечения оно помогает избежать «ада зависимостей» — ситуации, когда обновление какой-то части может поломать работу других.
Пример про презентации
В презентации могут быть исправления смысловых ошибок, опечаток и визуала. Исправление смысловой ошибки гораздо серьёзней и важнее остальных: если не исправить eё, нас не так поймут (мы обманем). А вот в остальных случаях мы отделаемся косыми взглядами.
Следуя идее выше, система версий для презентаций может быть устроена так. Для названия используем два числа А и Б, а полным названием версии будет А.Б, например, 1.2. Число А будет отвечать за серьёзные изменения (устранение семантической ошибки, новый контент), а число Б за мелкие исправления контента и визуала.
Представьте теперь, что вы читали версию 1.0. Потом видите свежую, 1.5, и думаете: «Окей, тут наисправляли недочёты, я их видел(а) в 1.0, не буду тратить время». Ещё через неделю видите 2.3 и уже думаете иначе: «Ага... Тут уже много чего исправили. Надо бы освежить, ведь я знаком(а) только с 1.0».
Как-то так это должно работать.
Список изменений
В хороших книгах есть предисловие к каждому изданию. Прочитав предисловия, вы можете понять, какие разделы появились раньше (изначальная цель авторов), много ли было исправлений (как часто авторы и редколлегия ошибаются), ну и почему книга распухла до 700 страниц.
Так, правило хорошего тона — поддерживать список изменений в проекте, будь-то годовой отчёт или программный продукт. Список изменений служит читателю: заказчику, коллеге, вам. С его помощью понятно, что именно изменилось с предыдущей версии.
Я считаю, что для софта список изменений (changelog на погромистском) необходим: будь-то внутренний проект или опенсурс. Хороший шаблон списка изменений вот этот — keep a changelog.
Для продуктов типа презентаций или отчётов (один документ) я оставляю список изменений где-то в начале, прям внутри документа.