Ветки и обновление ядра¶

Политика веток¶

master во всех трёх репозиториях — защищённая, стабильная ветка: изменения попадают в неё через отдельную ветку и слияние, а не прямым пушем. Смысл в том, что master в Metatron в любой момент можно безопасно взять как основу для submodule в Metatron-Research — там заведомо не будет незакоммиченного/сломанного промежуточного состояния.

Практическое разделение по репозиториям:

• Metatron — рабочие ветки на функциональность/рефакторинг (например, refactoring_2/self_order_loop, как сейчас), слияние в master — когда состояние действительно стабильно и стоит того, чтобы на него ссылались submodule-потребители.

• Metatron-Research — ветка на задачу или статью (Examples/2026_MyPaper/ внутри такой ветки, см. Metatron-Research). Каждая такая ветка фиксирует свой коммит Metatron — именно так достигается воспроизводимость результатов.

• Metatron-Docs — обычно один поток изменений в master (документация не версионируется по задачам так же, как расчёты).

Как обновить ядро в Metatron-Research¶

Обновление ядра — осознанный шаг, а не побочный эффект обычного git pull:

cd Metatron
git fetch
git checkout <нужный коммит/тег/ветка>
cd ..
git add Metatron
git commit -m "Обновление ядра Metatron до <версии>: <зачем>"

До коммита в Metatron-Research в git status будет виден submodule как «изменённый» (указывает на другой коммит) — это ожидаемо и означает, что обновление ещё не зафиксировано.

Как узнать, на каком коммите ядра посчитан результат¶

cd Metatron-Research/Metatron
git log -1

Или, не заходя в submodule, из корня Metatron-Research:

git ls-tree HEAD Metatron

Если результаты сохранялись через скриптовый слой (см. Шаг 5. Сохранение и загрузка результатов), дата и параметры расчёта также видны в manifest.txt рядом с результатами — но версия ядра туда сейчас не пишется явно, единственный надёжный источник — коммит submodule на момент расчёта.