git, и мультирепозиториевые атомарные коммиты, как?

потому что изменился интерфейс

Не меняй интерфейс.

Как делается атомарный коммит в git, если нужно его сразу применить для нескольких репозиториев? Какие существуют костыли?

Если это в конторе, то монорепа.

Как более реальный пример приближенный к миру Linux, я хочу изменить код интерфейса в kdelib, и так же изменить код в kapp1, kapp2 которые зависят от kdelib, потому что изменился интерфейс.

Версии у либ, зависимости от определенной версии в kapp1, kapp2 же.

Ну так выкати одним PR’ом изменения АПИ и соответствующие изменения в kapp1/2. Проблема в чем? Ты сломал, ты чини. master должен всегда быть работоспособным. Можешь поиграться с ветками, если прям так хочется полового разнообразия:

master
 +----- IOL-2112
        +----- IOL-2112-kdelib
        +----- IOL-2112-kapp1
        +----- IOL-2112-kapp2

Где IOL-2122 - номер таски или имя задачи Потом делаешь PR’ы на слияние трех веток в IOL-2112, после слияния делаешь PR на слияние IOL-2112 в master

Этот интерфейс не является внешним, а скорее внутренний для проекта, поэтому такой совет не подходит.

Можно ли создать один единственный PR для внесения изменения в три отдельных репозитория? На какой платформе?

Проблема в чем?

Можно не считать это проблемой, я уверен некоторым поведение CVS даже больше нравится.

Монорепозиторий действительно помогает в таких ситуациях.

Версии у либ, зависимости от определенной версии в kapp1, kapp2 же.

Получается выходит новая версия kdelib, которая абсолютно бесполезна, потому что это мертвый код который не могут использовать приложения. А у kapp1, kapp2 версии по какой то причине задерживаются, и поэтому не собираются с самой новой версией. Примеры могут быть странными, но меня пока реальность не волнует.

Ты какие-то странные вещи пишешь. Система контроля версий к твоей задаче отношения не имеет, это вопрос системы обновления кода на проде - она должна брать те версии (коммиты) разных частей проекта, которые между собой взаимно совместимы. А в каком порядке и когда ты их в репу закоммитил - совершенно не важно.

Монорепозиторий действительно помогает в таких ситуациях.

Кстати, пикрелейтед https://www.reddit.com/r/ProgrammerHumor/comments/1e2mpzk/softwarearchitectsaretherootofallevil/

Получается выходит новая версия kdelib, которая абсолютно бесполезна, потому что это мертвый код который не могут использовать приложения. А у kapp1, kapp2 версии по какой то причине задерживаются, и поэтому не собираются с самой новой версией. Примеры могут быть странными, но меня пока реальность не волнует.

Если ты это про опенсорс, то можно делать патчи к старым версиям либ типа kdelib 3.42_morkobka0.1, если про работу в фирме - то возможно, лучшим решением проблемы будет свалить оттуда)

У меня нету задачи, речь о атомарном коммите.

Атомарный коммит в несколько разных реп сделать невозможно. И не нужно, почему - я выше написал.

У меня сложилось впечатление, что у тебя там по коммиту сразу деплой автоматический делается и отовсюду берутся последние версии. Не надо так делать в сложных системах, это годится только для мелких проектов где всё тривиально (да и в них такая практика - плохая, но нубы её реализуют и и них не ломается, да).

Нужно где-то держать описание того, какие именно версии тебе нужны, обновлять атомарно именно его. А в репах просто наборы коммитов, ни к чему не обязывающие.

Атомарный коммит в несколько разных реп сделать невозможно.
Нужно где-то держать описание того, какие именно версии тебе нужны, обновлять атомарно именно его.

git в отличие от CVS держит пофайловые список для коммитов, держать порепозиторный список тоже можно, интересуют различные костыли. Так что с «невозможно» я не согласен.

Например можно добавлять в сообщение коммита в конец строки вида repo_id:commit_id, и внешний инструмент который будет правильно делать git pull, checkout.

Нужно где-то держать описание того, какие именно версии тебе нужны, обновлять атомарно именно его.

Вот это уже интересно, как бы ты реализовал этот список? По своему индивидуально для каждого проекта?

В общем не возможно.

Как уже выше сказали: либо монорепа. Либо не ломать интерфейс. Точнее ломать постепенно с grace периодом на deprecated части.

У меня нету задачи

Есть только работа?

В git есть submodule. Добавленный сабмодуль указывает на коммит в исходном репе (которое подтягивается). Соответственно, зависимости в проект можно подтянуть по этим данным.

Правда следить покоммитно гемор и я такого не делаю в своих проектах (тупо тащу последний мастер в проекты), но это лично мне так удобнее.

git в отличие от CVS держит пофайловые список для коммитов,

cvs тут ни при чём, это древняя штука, для деплоя не проектировавшаяся, чисто логи разработки. Все современные vcs хранят коммиты атомарно, а не отдельные файлы. Но объект этой атомарности как раз называется репозиторием. Ты же зачем-то хочешь назвать репозиторием что-то другое, более маленькое чем атомарный объект, какой в этом смысл непонятно.

Вот это уже интересно, как бы ты реализовал этот список? По своему индивидуально для каждого проекта?

Как угодно. Можешь текстовым файлом со списком пакет=версия, можешь таблицей в базе с теми же двумя колонками, наверно есть и ещё какие способы. Конкретика в зависимости от структуры твоего проекта (как в плане софта, так и в плане железа и географического распределения) и того как там удобнее это сделать.

Вот это уже интересно, как бы ты реализовал этот список?

У js есть npm для этого, у rust - cargo, даже у пхп есть composer, а вот у сишечки полная свобода - как сказал firkax можно сделать текстовым файлом со списком пакет=версия)

как бы ты реализовал этот список?

go.mod

По описанию чем-то похоже на топики в Gerrit.

меня интересует только атомарность комитов применяемых сразу к нескольким репозиториям.

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

С использованием пакетов есть нюанс - нужно пакетить. Те это +devops активность.

Я в свое время выбрал сабмодули именно потому, что у есть git в каком-то виде в любом случае (gitlab, github и тд) и просто можешь подтягивать внутренние зависимости. А на опакечивание время не тратить.

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

но сабмодули в 2025 году - эт такоэ…

// о, тут уже и до них дошли. (тред я, как водится, не читал)

Если обновить kapp1 отдельно от kdelib, или наоборот, то приложения будут неработоспособны.

В таком случае репозиторий kdelib добавляется субмодулем в репозиторий kapp1, и коммит на kapp1 включает в себя обновление субмодуля. Система сборки kapp1 в таком случае использует kapp1 из субмодуля и ничего другого искать не пытается. Про какую-либо совместимость вперёд и назад в kdelib мы в таком случае забываем, гарантируется только сборка с субмодулем.

но сабмодули в 2025 году - эт такоэ…

А какие альтернативы с аналогичным расходом ресурсов на поддержку решения есть?

многое перечислено выше.

я для себя (геораспределенная команда чуть больше 10 чел) выбрал деволпс+бинарные пакеты для всех компонентов.

мастер репу с сабмодулями тоже пробовали - не зашло.

Как более реальный пример приближенный к миру Linux, я хочу изменить код интерфейса в kdelib, и так же изменить код в kapp1, kapp2 которые зависят от kdelib, потому что изменился интерфейс. Если обновить kapp1 отдельно от kdelib, или наоборот, то приложения будут неработоспособны. Нужна атомарность.

Нужна правильная поддержка semver.

Для примера библиотека kdelib 1.x, kapp1 и kapp2 требуют версию 1.x. Ты сломал интерфейс соответственно изменил первую цифру версии на kdelib 2.x, kapp1 и kapp2 продолжат требовать версию 1.x так как версия 2.x подразумевает уже другой не совместимый интерфейс. После этого последовательно правишь kapp1 и kapp2 для их перехода на версию kdelib 2.x. kdelib 1.x и kdelib 2.x должны быть разными пакетами желательно, чтоб к примеру уже исправленный kapp1 использовал kdelib 2.x а еще не исправленный kapp2 использовал kdelib 1.x.

Сейчас по лучшим практикам любой проект нужно разбить на как можно большее количество микросервисов, проектов, и репозиториев git.

Эти практики устарели 20 лет назад, сейчас модно все хранить в одном монорепозитории гигов на 100.

Монорепозиторий действительно помогает в таких ситуациях.

Обычно это признак дегенеративного подхода.

Потом это заканчивается вопросами вида: А как сделать коммит только на один файл, или как 4000 тысячи коммитов в секунду. И подобный бред.

Причём этим страдают многие. Включая Microsoft.

монорепы это деградантство

Удобное деграданство

Эти практики устарели 20 лет назад, сейчас модно все хранить в одном монорепозитории гигов на 100.

Не, вот это как раз устарело лет на 15. Так только гигантские говноконторы типа мелкомягких и лицекниги делают. Поэтому у лицекниги до сих пор Mercurial

А как сейчас делают не гигантские конторы? Я одно время поддерживал проект, распределенный монолит по сути. Каждый микросервис в своей репе. Любая задача сводилась к комитам в 3-5 репозитория. Это очень неудобно, мягко говоря. Если, скажем Вася закомитил фичу в A, B, C, а Петя закомитил в B, C, D. Потом нашли баг на проде в васиной задаче. Надо откатывать изменения в A, B, C, D. С монорепой надо чистить только ее одну

ничего удобного там нет, люди которые это продвигают - дегроды

Ну конечно, там фронт только от меркуриал, а хранилище коммитов свое.

Как и у MS только фронт от git. Потому что git не вытягивает настолько огромные монорепы.

Каждый микросервис в своей репе.

Надо откатывать изменения в A, B, C, D.

Микросервис – это вещь в себе. Распределённый монолит – misdesign. 4 репы нужно откатывать только если совершенно 4 ошибки.

Микросервис – это вещь в себе.

С чего это? Он не использует общеконторские либы, которые лежат в репах E,F,G ?

В общем множественные репы нежизнеспособная конструкция без ручного пининга зависимостей по коммитам для каждой репы. А потом окажется, что репа A зависит от репы B@1000, а репа C зависит от репы B@2000, а репа B убежала уже до коммита 10000.

А какие альтернативы с аналогичным расходом ресурсов на поддержку решения есть?

Боюсь, что альтернатив «с аналогичным расходом ресурсов» попросту не существует - есть только с куда меньшим. Вы когда затягиваете зависимости в виде кода, а не бинарей, то подписываетесь тянуть за этим кодом еще сборочные зависимости и сопутствующую инфраструктуру (еще и собирать нужно каждый раз куда больше нужного), и при этом совершенно ничего не выигрываете: что версии бинарников, что ссылки на коммиты в гите протухают одинаково быстро.

А я бинарники не собираю, у меня Python+JS. Поэтому весь максимум который я получаю - вызвать в зависимостях npm i + pip install.

С чего это? Он не использует общеконторские либы, которые лежат в репах E,F,G ?

Определённых версий. Не имеет значения куда при этом указывает master.

В общем множественные репы нежизнеспособная конструкция без ручного пининга зависимостей по коммитам для каждой репы. А потом окажется, что репа A зависит от репы B@1000, а репа C зависит от репы B@2000, а репа B убежала уже до коммита 10000.

При построении распределённого монолита и не такое бывает. Только при чём тут микросервисы.

Микросервис – это как Ruby on Rails. Когда на скриптах делается быстро приложение. И вся работа сваливается на сервисы. Которые уже в зависимости от ожидаемой нагрузки проектируются.

Любой микросервис – развитие подобного подхода. Пришла работа – сунуть её в соответствующий сервис, забыть.

И какая разница, обновился crontab, например. И какой он вообще версии. Всё что имеет значение – совместимость API. Если они не совместимы, то просто планируется переход. Причём, как вариант, одновременная поддержка двух версий API.

Проблема слома API это тоже не про микросервисы. И не про git. И не про монорепу.

Определённых версий. Не имеет значения куда при этом указывает master.

Вот я говорю пинишь версии, а потом не обновляешь. А потом если надо баг исправить, то трахаешься несколько дней.

Вот я говорю пинишь версии, а потом не обновляешь. А потом если надо баг исправить, то трахаешься несколько дней.

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

Вот у MS есть монстр на GH: https://github.com/Azure/azure-sdk-for-java/ - так делать точно не нужно, даже для одной технологии/ЯП

весь максимум который я получаю - вызвать в зависимостях npm i + pip install

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

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

PS Ну да, не у всех так наверное. Но позволять разработчикам свапать версии без обоснования и плана действий - это всегда приводит к внезапным сайт эффектам (в энвире разработки или в энвире деплоя).

Вот я говорю пинишь версии, а потом не обновляешь. А потом если надо баг исправить, то трахаешься несколько дней.

Потом обновляйте и всё.