Как объединить две ветки правок рукописного шрифта

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

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

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

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

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

Создайте понятную структуру папок, например:

Названия можно выбрать другие, важно не путать их. Не называйте все варианты final, final2 и final_new. Подпишите каждую копию коротким именем участника или задачи и номером базы, например base-1.4__branch-letterforms. Если используете систему контроля версий, ветки можно хранить там; если нет, достаточно отдельных копий с запретом редактирования папки base.

До работы согласуйте границы: какие знаки, таблицы или настройки можно менять, где оставлять комментарий и кто решает спорные случаи. Обозначьте ответственного за итоговую сборку. Это не даёт одному участнику случайно перезаписать результат другого и избавляет от ситуации «оба думали, что собирает второй».

Не объединяйте файлы, пока у каждой ветки нет карты правок. Запись должна позволять понять не только что изменили, но и почему. Для каждого пункта попросите указать:

Например, «расширил н» мало помогает. Лучше: «в узкой подписи интернет н сливается с соседней; расширил правую стойку на варианте с номером 3; проверить слова на, ни, не и строку целиком; ширину глифа менял, парный интервал нт не проверял». Такая заметка даёт сборщику критерий приёмки и сообщает, что ещё нужно испытать.

Отделяйте наблюдения от решений. Факт «длинная диагональ к задевает линию клетки» отличается от решения «укоротить диагональ». Если другой человек предложил исправление по-своему, сравните оба результата с общей проблемой, а не с формулировкой правки.

Сведите списки обеих веток в таблицу. Каждому изменению назначьте одну из трёх категорий:

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

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

Если обе ветки меняли одну букву, не выбирайте файл по дате или по тому, кто редактировал последним. Поставьте рядом базовый знак и оба варианта в одинаковом масштабе, а затем проверьте одну и ту же проблему. Для формы оцените узнаваемость и связь с родственными знаками; для ширины — набранные пары и слова; для интервала — саму пару в нескольких контекстах.

Затем сформулируйте критерий выбора. Например: «строчная ж должна отличаться от х в размере карточки и не создавать чрезмерно широкие слова». Критерий позволяет отказаться от варианта, который красивее в крупном размере, но хуже решает реальную задачу. Если оба решения частично успешны, объединяйте их как новую правку только после того, как определили совместимые части и записали, что именно берёте из каждого.

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

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

Проверьте три слоя:

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

Участник А исправляет нижний выносной штрих, который задевает соседнюю строку. Участник Б замечает, что форма «д» слишком похожа на «а», и раскрывает верхнюю часть знака. Если взять целиком версию Б, выносной элемент может остаться слишком длинным; если целиком взять версию А, проблема различимости сохранится.

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

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

Дата сохранения ничего не говорит о соответствии задаче. Сравнивайте каждое решение с общей проблемой и критериями.

Если после объединения непонятно, кто менял знак и зачем, следующую ошибку будет трудно расследовать. Оставляйте заметки вместе с кандидатом.

Участники могут предпочитать разные формы. Выберите проверяемую задачу, поставьте варианты в контекст и примите решение по результату.

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

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

Сначала установите, какие правки уже присутствуют в каждой копии. Выберите одну общую базу и перенесите изменения поверх неё по одному, повторно проверяя зависимости. Не складывайте файлы из двух разных состояний в одну папку.

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

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

Объединяйте, когда участник закончил ограниченную группу изменений и передал карту проверки. Не ждите, пока накопятся десятки несвязанных правок; при этом слишком частое слияние незавершённых экспериментов создаёт лишнюю работу.

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

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