У меня есть простой текстовый файл 190 МБ, который я хочу отслеживать на GitHub.

Текстовый файл - это файл лексики произношения для нашего механизма преобразования текста в речь. Мы регулярно добавляем и изменяем строки в текстовых файлах, и различия довольно малы, поэтому в этом смысле они идеально подходят для git.

Тем не менее, GitHub имеет строгое ограничение размера файла 100 МБ. Я попробовал сервис GitHub Large File Storage, но он загружает новую версию всего файла 190 МБ каждый раз, когда он изменяется, так что если я пойду по этому пути, он быстро увеличится до многих гигабайт.

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

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

Другие идеи?

редактировать: Мне известно об ограничении размера файла в 100 МБ, описанном в аналогичных вопросах здесь, на StackOverflow, но я не считаю свой вопрос дубликатом, потому что я спрашиваю о конкретном случае, когда различия небольшие и частые (я не пытается загрузить большой файл ZIP или что-нибудь). Тем не менее, я понимаю, что git-lfs подходит только для файлов, которыередко изменить, и этот нормальный git будет идеально подходить для файла, который я описываю; за исключением того, что GitHub имеет ограничение на размер файла.

ОбновитьВчера я экспериментировал с созданием небольшой кроссплатформенной программы, которая разделяет и объединяет файлы в файлы меньшего размера, используя git-хуки. Это отчасти работает, но не совсем удовлетворительно. Вам нужно исключить ваш большой текстовый файл из .gitignore, что делает git не осведомленным о том, изменился он или нет. Разделенные файлы изначально не обнаруживаютсяgit status или жеgit commit и приводит к той же самой проблеме, как описано в этом вопросе SO, который довольно раздражает:Сценарий предварительной фиксации создает файл mysqldump, но «ничего не фиксируется (рабочий каталог очищен)»? Настройка задачи cron (linux) и запланированной задачи (windows) для автоматической регулярной регенерации разделенных файлов может исправить это, но автоматическая настройка не так проста, может вызвать проблемы с производительностью на компьютере пользователя и просто не очень элегантна решение. Также могут потребоваться некоторые хакерские решения, такие как динамическое изменение .gitignore, и вы ни в коем случае не получите различий между фактическими текстовыми файлами, только разделенными файлами (хотя это может быть приемлемо, поскольку они будут очень похожи).

Поэтому, поспав на нем, сегодня я думаю, что подход с использованием git hook, в конце концов, не очень хороший вариант, так как в нем слишком много причуд. Как было предложено @PyRulez, я думаю, что мне придется взглянуть на другие сервисы, кроме GitHub (к сожалению, так как я люблю github). Хостинговое решение было бы предпочтительным, чтобы избежать необходимости управлять нашим собственным сервером. Я также хотел бы, чтобы это было публично доступно ...

Обновление 2Я рассмотрел некоторые альтернативы GitHub и в настоящее время склоняюсь к использованию GitLab. Я связался со службой поддержки GitHub о возможности повышения лимита в 100 МБ, но если они этого не сделают, я просто переключусь на GitLab для этого конкретного проекта.