Комментарии 8
Тут проблема видится в том, что на самом-то деле для документации с её динамики не нужна глубокая история. Возможно, какие-то отдельные контрольные точки и всё. В результате 99.9% хранимых данных в документации изначально представляют собой мусор. А если ещё и текст документации ещё и в каких-то бинарных форматах хранится, то дело совсем печально ставится. Нужно поставить точку или запятую? Извольте два мегабайта бесполезного коммита сделать. Или сразу 20, если документ большой. И так на каждой опечатку. И вся эта история получается бесполезной, так как даже diff по ней не сделать, и никто и никогда не будет ей пользоваться.
для документации с её динамики не нужна глубокая история
Документация кладётся в репозиторий не ради глубокой истории, это просто сайд-эффект. Она кладётся для того чтобы синхронизировать версионирование документации с изменениями в самом приложении. Чтобы например был чёткий и ясный ответ на вопрос "где почитать документацию к версии v1.2.3" - там же где и исходники версии v1.2.3. Ну и появляется возможность в одном мёрж-реквесте добавлять и ревьювить фичу и одновременно же документацию по ней. А не так что "ну сначала надо залить фичу, а потом идти на конфлюенс её описывать", что часто заканчивается забиванием на эту документацию полностью.
По моему опыту документация рядом с кодом очень удобна для описания микросервисов, но далеко не всю документацию удобно так вести. Это связано с тем что некоторую документацию потом просто будет не найти в коде. Так что лучше конечно комбинировать Confluence и доку в коде, тогда на проекте будут извлечены преимущества обоих подходов.
Как долго происходил переход от конфлюенса, требовались ли дополнительные трудозатраты на перечитку всей документации?
Возможно я немного опоздал в вопросом, но в реальности о каком размере идёт речь?
Как Git LFS влияет на опыт ведения документации рядом с кодом