Истории B-Maker

Feature storyВерсии

Больше никаких final-final.docx.

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

Полноэкранное сравнение двух версий текста в B-Maker
Основная идея

Глава остаётся одной главой. Редакции живут внутри неё как именованные версии, поэтому структура рукописи и история правок не расходятся.

Знакомая проблема папки с файлами

Большая правка часто начинается безобидно: сделать копию файла перед изменениями. Потом появляется chapter-7-v2.docx, затем chapter-7-final.docx, потом chapter-7-final-edited.docx. Через несколько итераций имя файла начинает выполнять работу, которую должна делать сама система.

Главная проблема даже не в некрасивых названиях, а в неопределённости. Какой файл текущий? Что именно поменялось между двумя версиями? Редактор комментирует тот же текст, который сейчас правите вы? Можно ли спокойно вернуть старую концовку, не собирая её из резервных копий?

Шаг 1. Структура рукописи остаётся стабильной

В B-Maker сцена, глава или статья остаётся одним структурным элементом, а текст у неё может иметь несколько версий. В дереве не нужны дубли вроде «старая», «новая» и «точно новая».

Перед заметной переработкой создайте новую версию и дайте ей понятное имя: «Короче вступление», «Редакторская правка», «Альтернативный финал» или просто дату, если этого достаточно.

Одна глава B-Maker с несколькими именованными редакциями и текущей версией

Шаг 2. Переписывать, не уничтожая предыдущий ответ

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

Это немного меняет поведение автора: становится проще экспериментировать, а не защищать вчерашний текст только потому, что потом его будет неприятно восстанавливать.

Шаг 3. Сравнивать, а не надеяться на память

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

Это полезно не только для вычитки. Сравнение отвечает на редакторские вопросы: действительно ли текст стал короче? Какой пример исчез? Не вырезали ли мы во вступлении контекст, который всё ещё нужен дальше?

Скриншот: сравнение двух именованных версийПолноэкранное сравнение одной главы. Лучше выбрать короткий фрагмент, где хорошо видны добавления и удаления.assets/img/bmaker/bmaker-story-version-02.webp

Шаг 4. Заблокировать то, что уже не должно двигаться

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

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

Шаг 5. Комментарии остаются рядом с текстом

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

Заблокированная версия B-Maker с комментарием к фрагменту и общим комментарием

Версии должны уменьшать страх, а не добавлять процесс

Это не Git для писателей. Автору не нужны commits, branches, merge-стратегии и словарь системы контроля версий только ради сохранения предыдущего черновика.

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

Связанные материалы

Управление версиями рукописи · Как организовать роман · От идеи до главы

Переписывайте главу, а не имя файла.

Храните редакции внутри проекта, а структуру рукописи оставляйте стабильной.

Открыть B-Maker О продукте