Всем доброе утро! Коллеги, нужен совет по организации работы Markdown + Git + три версии продукта в "разработке" паралелльно. Мне кажется, я не вывожу то, что происходит.

Ситуация такая - есть продукт, на него ведем "часть документации" в markdown. Храним все в собственном git-хранилище. Каждая страница документации имеет два варианта (рабочее описание и описание, которое войдет в релиз). Решили таким образом отслеживать изменения, требующие документирования. Когда разработчик обновляет свою часть описания, добавляется "файл-маркер", по которому я понимаю, что описание обновлено и требует "доработки". Проблемы начинаются, когда мне предложили правку между ветками "переносить cherry-pick-ами". Продукт "относительно" новый, но уже три ветки разработки и меня напрягает, что могу тупо запутаться в такой схеме при переносе (например, я переношу из 2ой версии в 3ю документацию к публикации, а в 3-ей версии что-то поправили (а свои файлы-маркеры я не перетаскиваю).
Сейчас я редактирую все в своей ветке (например 2-edit), и вливаю изменения в основное хранилище, и потом этот коммит (которым я вливаю 2 -edit в 2 ) я пытаюсь перетащить в 3 и 4 "редакции".

Переносить правку между версиями совсем руками, кажется довольно трудозатратным. Как лучше поступить (и возможно, можно перестроить сам процесс?)  в подобных случаях?

может документацию к исходникам положить?

А у вас фичи свободно мигрируют между тремя версиями? Или всё таки 1->2->3?

стараются держаться идеи  1->2->3, но в ветке первой версии могут появиться "фичи из следующей версии", которые стали полезны (такое перемещение уже было, причем в следующей версии они "доработали вновь добавленный механизм")

в такой схеме ничего кроме как черипикать и переносить руками не остаётся, причем разработчикам тоже :(

Не представляю какая жуть потом решать конфликты 😱

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

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

может быть всё таки документацию держать рядом с исходниками? Тогда они хотя бы будут синхронны

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

звучит как «гит вручную»

у меня пока не получается перенести и быть без доп.проверки уверенной, что дока для 2ой версии будет актуальна для 3-ей (куда переношу), Например. В этом и загвоздка.

https://habr.com/ru/company/selectel/blog/514576/ кейс про Hugo от selectel

Клево!!

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

О, кстати, у них лица сгенерированы через thispersondoesnotexist

Достойное применение технологии

Ребята, а есть у кого-то на примете инструменты, которые бы позволяли "тестировать" сгенерированные PDF (md -> latex -> pdf)?
В рамках отладки шаблонов мы меняем сотни документов и где-то может починиться , а где-то - сломаться.

Как вы с этим работаете? Как проводите регрессионное тестирование большого объёма документов?

А что именно тестировать? Верстку?

Да. Верстка, перекрытие текста.

Оу.

Полиграфия прожила 400 лет и буквально 10 лет не дожила до prepress-as-a-code