Что произошло

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

Ежедневные цены на сельхозрынках, еженедельные сведения о программах поддержки и обновляемые векторные фрагменты карт устроены иначе. Это воспроизводимые машинные результаты, для которых просмотр огромного JSON-изменения человеком почти ничего не даёт. Автоматизация собирает их в отдельной ветке, создаёт коммит без прежней истории и принудительно отправляет новую версию.

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

Почему это важно

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

Это не универсальная замена серверу. У GitHub есть ограничения на размер, частоту и характер хранения файлов; для гигабайтных кадастровых карт автор оставил отдельное объектное хранилище. Ему нужны недорогая раздача без платы за исходящий трафик и поддержка HTTP-запросов диапазона, которой требуют геопространственные форматы.

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

На практике

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

1. Оставьте для редких и значимых изменений запросы на слияние, проверки структуры и понятный журнал изменений.
2. Публикуйте частые воспроизводимые файлы в изолированной ветке; собирайте её во временном каталоге, чтобы не смешивать с рабочей историей.
3. Запрашивайте небольшие JSON-файлы прямо из публичной ветки, но проверьте ограничения GitHub и политику доступа к данным.
4. Для объёмных файлов подключите хранилище, подходящее для диапазонных HTTP-запросов, либо добавляйте снимок ветки в каталог сборки сайта.
5. В задачах по расписанию отделяйте временную недоступность внешнего API от ошибки кода. Автор завершает такую задачу кодом EX_TEMPFAIL (75), сохраняет вчерашний снимок и пишет краткое уведомление вместо ложной тревоги.

Есть и два неочевидных места: git diff --quiet не замечает неотслеживаемые файлы при первой загрузке, а правила сопоставления путей отличаются от шаблонов оболочки. Эти случаи лучше покрыть отдельной проверкой git status --porcelain и испытаниями на пустом репозитории.

Итог

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

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