К содержанию
Содействиебиблиотека
XСравнение исследованийX03-0203 · Раздел 03

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси (часть 6)

Обновлён
10.11.2026
Редактор
gemini-3.8
Источников
1
Утверждений
71
Объём
14 956 из 15 000 знаков
На странице
  1. Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 6 из 11
  2. Утверждения темы
  3. Фрагменты корпуса темы
  4. [LG-193-F033] — LG-193, фрагмент 04, строки 11-80, тема «assistant»
  5. assistant
  6. [LG-193-F039] — LG-193, фрагмент 05, строки 1-53, тема «`text»
  7. [LG-193-F041] — LG-193, фрагмент 05, строки 58-88, тема «assistant»
  8. assistant
  9. [LG-193-F045] — LG-193, фрагмент 05, строки 141-173, тема «assistant»
  10. assistant

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 6 из 11

Назначение и границы: Документ входит в блок X библиотеки материалов «Содействие» (Гомель). Тематический охват: Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси. Ответственная линия: корпус. Статус материала: есть проверенные пруфы — фрагментов 102, утверждений 539, проверенных 13.

Утверждения темы

Фрагменты корпуса темы

[LG-193-F033] — LG-193, фрагмент 04, строки 11-80, тема «assistant»

assistant

Для твоего режима GitHub Free вполне достаточно. А Obsync я бы привёл в порядок с сохранением истории — новый репозиторий ради «красивых коммитов» заметной пользы не даст.

Коммит и пуш — два разных действия

ДействиеЧто происходит
CommitСохраняет выбранные изменения в локальную историю проекта с описанием. Можно сделать без интернета.
PushОтправляет уже созданные коммиты и соответствующую ветку на GitHub.
DeployОбновляет работающий сайт или приложение. Это отдельное действие, которое при желании автоматизируют.

Например: агент исправил форму → сделал коммит «Исправлена отправка формы» → отправил его на GitHub → обновил сайт.

Можно сделать пять коммитов и отправить их одним пушем. Несохранённые в коммит изменения пуш не отправит. Базы данных, пользовательские загрузки и секреты тоже требуют отдельного бэкапа.

Что даёт бесплатный GitHub

Сам Git бесплатен. У сервиса GitHub есть тарифы:

Возможность GitHub FreeПрактический смысл для тебя
Неограниченное число приватных репозиториев и участниковМожно хранить проекты отдельно и подключать агентов
Ветки, история, pull requestsМожно собирать изменения из разных приложений
Actions: 2 000 минут в месяцДостаточно для умеренного количества коротких автоматических проверок
Actions: 500 МБ хранения артефактовОграничение результатов сборок и проверок, не размера всех репозиториев

Это актуальные условия из описания тарифов и таблицы включённых ресурсов.

Условный расчёт: проверка на обычном Linux runner занимает 5 минут, запускается 10 раз в рабочий день — около 1 100 минут за 22 дня. Но квота общая для аккаунта: несколько активно разрабатываемых проектов могут её израсходовать.

Важное ограничение Free: защита веток приватных репозиториев доступна на платных планах. Поэтому правило «агент пишет только в свою ветку» на Free может оставаться договорённостью, а не техническим запретом. Документация GitHub

Тебе необязательно выбирать между “просто бэкапом” и сложной инфраструктурой. Можно сохранить нынешнюю работу и добавить только полезное:

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

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

Что конкретно с Obsync

Проверил репозиторий кода: сейчас в истории текущей ветки 315 коммитов, упакованные Git-объекты занимают примерно 68 МБ, текущая рабочая папка чистая. Это небольшая история — причин обнулять её ради размера нет.

При этом текущая ветка — refactor/landing-test-1.10.3.8, тегов релизов нет. При предыдущем осмотре в отдельной рабочей папке EN были незакоммиченные изменения. Поэтому сначала нужно определить, какое состояние считать основной рабочей версией, а не просто взять одну папку за эталон.

Старые коммиты приложению для запуска не нужны. Но они помогают ответить:

  • почему код сделан именно так;
  • какое изменение вызвало поломку;
  • как вернуть отдельную функцию;
  • чем рабочая версия отличалась от новой.

«Сейчас всё работает» — хороший момент обозначить стабильную точку. Но это не делает историю бесполезной: она особенно пригодится после следующей поломки. Агентам не приходится читать все 315 коммитов при каждой задаче, поэтому само наличие истории не создаёт постоянного расхода токенов.

Как я бы организовал это на практике

  1. Определить проверенную базовую версию Obsync, сверив её с работающим приложением и незавершёнными изменениями.
  2. Отметить её тегом — именованной точкой возврата.
  3. Отдельными коммитами привести в порядок структуру, инструкции агентам и команды запуска/проверки.
  4. Дальше сохранять изменения небольшими осмысленными коммитами; параллельную работу вести в отдельных ветках и рабочих папках.

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

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

Для Obsync мой выбор: сохранить историю, обозначить стабильную базу и навести порядок с сегодняшнего дня. Бесплатного GitHub для такого процесса достаточно.

[LG-193-F039] — LG-193, фрагмент 05, строки 1-53, тема «```text»

Проверенная основная версия — main
                ↓
Агент создаёт ветку задачи в этой же папке
                ↓
Меняет код и связанные документы
                ↓
Делает понятные коммиты и пушит ветку
                ↓
Выкладывает эту версию в тестовый контейнер
                ↓
Ты проверяешь результат на сайте
                ↓
Агент объединяет готовую задачу с main
                ↓
В прод отправляется проверенная сборка

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

Тебе необязательно открывать GitHub и вручную проверять pull request. Агент может выполнить Git-операции сам в рамках согласованного процесса. Ты по-прежнему оцениваешь результат на тестовом сайте.

3. А если одновременно нужны два агента

Допустим, Claude переделывает главную, а мне ты поручаешь исправить отправку формы. Тогда появляются отдельные папки:

obsync/                 основная версия — main
obsync-homepage/        Claude: главная + документы
obsync-form-fix/        Codex: форма + документы

Это и есть применение worktrees. Каждый агент получает целый проект, но работает со своей задачей и не меняет файлы другого.

Дальше задачи принимаются последовательно:

  1. Исправление формы выкладываем в тестовый контейнер, проверяем и включаем в main.
  2. Ветка главной получает это исправление из main.
  3. Проверяем главную уже вместе с исправленной формой, затем включаем её в main.

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

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

Для начала нам достаточно единого репозитория, одной рабочей папки и последовательной работы агентов. Worktrees добавляем только под реальные параллельные задачи. GitHub Actions и доска Projects для этой схемы необязательны.

[LG-193-F041] — LG-193, фрагмент 05, строки 58-88, тема «assistant»

assistant

Объединяет один выбранный тобой агент — или ты сам. Git выполняет объединение, а агент разбирает конфликты и проверяет результат. GitHub Actions для этого не обязателен.

Допустим, три агента закончили:

Claude → ветка с новой главной
Qwen   → ветка с загрузкой файлов
Codex  → ветка с настройками

Ты говоришь мне:

Собери эти три ветки вместе, проверь совместимость и выложи на TEST.

Я выполняю задачу:

  1. Получаю три ветки с GitHub.
  2. Создаю отдельную ветку и рабочую папку для общей версии.
  3. Последовательно объединяю туда изменения всех трёх.
  4. Если изменения пересекаются — разбираю конфликты. Если обнаруживается противоречие в требованиях, уточняю у тебя.
  5. Проверяю общую версию и выкладываю в тестовый контейнер.
  6. После принятия результата переношу объединённые изменения в main.

GitHub Actions может автоматически проверить получившийся код, собрать образ и даже выложить его на TEST, если мы это настроим. Но он выполняет заранее написанные команды: сам не решает, какое поведение правильное при противоречащих изменениях.

Причём «Git объединил без конфликтов» не означает «всё работает». Например, один агент поменял API, а другой использовал старый API в другом файле — текстового конфликта нет, но функция сломана.

Для тебя я предлагаю простой порядок: агенты делают независимые задачи → одному из них поручаешь собрать готовые ветки → проверяешь общий результат на TEST. Постоянный отдельный «агент-оркестратор» для этого не нужен.

[LG-193-F045] — LG-193, фрагмент 05, строки 141-173, тема «assistant»

assistant

Да, может. Один локальный репозиторий можно отправлять и в два аккаунта GitHub, и одновременно в GitHub и свой GitLab/Gitea. Это нормальная схема для зеркала или дополнительной копии.

В Git можно настроить несколько удалённых адресов — remotes:

Локальный Obsync — код, документы, история
       ├── origin → основной репозиторий GitHub
       └── backup → GitLab/Gitea на твоём VPS

Агент создаёт один коммит, затем отправляет его в оба места. История и идентификаторы коммитов будут одинаковыми. Для каждого сервера или аккаунта настраивается свой доступ — например, отдельный SSH-ключ.

Я бы назначил один репозиторий главным:

Основной GitHubДополнительный GitLab/Gitea
Сюда подключаются веб-агентыПолучает копию
Здесь появляются ветки задачХранит нужные ветки и теги
Отсюда собираем результатИспользуется для восстановления

Если разрешить агентам независимо работать на обоих серверах, это тоже возможно, но появится дополнительная обязанность: собирать и синхронизировать изменения между ними. Git сам этого не делает.

Несколько важных деталей:

  • Отправка в два места не является одной неделимой операцией: GitHub может принять изменения, а VPS оказаться недоступен. Агент должен проверить оба результата.
  • Обычный пуш отправляет выбранную ветку. Для полной копии нужных веток и тегов требуется отдельная настройка.
  • Через Git переносятся код и история. Задачи, комментарии, настройки CI и секреты между GitHub и Gitea автоматически не копируются.
  • Зеркало, повторяющее удаления, не заменяет резервную копию с историей восстановления.

Для тебя разумно: GitHub — основное место совместной работы агентов, Gitea/GitLab на VPS — дополнительная копия. Два аккаунта GitHub тоже подойдут, но отдельный сервер даёт больше независимости. А базы данных и загруженные пользователями файлы Obsync по-прежнему нужно резервировать отдельно.