Небольшие сниппеты кода в C++ - как расшаривать между проектами, версионировать, поддерживать в актуальном состоянии в проектах?

1. Сделай header-only (?) статическую библиотеку и тяни ее
2. Можно засунуть сниппеты на gist.github.com, и затем притяшгивать и мержить в основной репозиторий (subtree merge). Не очень удобно, но съедобно

Создавать крошечные библиотеки на каждый чих класс?

Имхо это самый c++ way. Всё что можно делать [шаблонным ]хидеронли.

Распихивать по опенсорс-проектам типа boost, а остальные заводить в тулкиты, которые хостит работодатель, типа libEmployerNameUtils?

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

Создавать крошечные библиотеки на каждый чих класс?

Разумеется.

Просто заводить по отдельному репозиторию на каждый сниппет и делать

Не понял почему это противопоставлено предыдущему пункту - да, крошечные библиотеки и на каждую свой репозиторий.

git pull в каждом проекте? В принципе, можно обойтись тэгами в git.

Совсем не понял при чём тут pull и тэги. Варианта, по сути, три:

• Просто копировать файлы библиотеки в проект. Я так делаю для мелких header-only библиотек, у которых в собственных репах больше кода для тестирования, ci и документации чем собственно кода библиотеки.
• Добавить как submodule.
• Добавить как внешнюю зависимость.

По последним двум пунктам зависит от того используется ли библиотека более чем одним проектом, может ли быть полезна сторонним проектам и насколько по собственному мнению я могу поддерживать стабильное API. Можно начать с submodule, потом если она станет нужна кому-то ещё вынести во внешнюю.

Вообще, с разных позиций тут противоречивые требования. Разработчику удобнее всего первые два пункта (т.е. бандлинг), но с точки зрения опакечивания и пользователя - это зло, т.к. раздувание реп (только для 1 варианта), дистрибутива, дублирование кода в разных проектах, невозможность централизованного обновления библиотеки (т.е. нашли уязвимость в библиотеки - исправили пакет, все потребители исправлены; каждую забандленную библиотеку нужно сначала найти, а потом руками исправить, и пересобрать пакет), но для своих собственных библиотек использующихся только в своих проектах я бы сделал исключение (по сути, это просто твой проект, разбитый на несколько реп). Внешняя зависимость таких проблем не имеет, но куча внешних пакетов на каждую мелочь - тоже не очень удобно, и совсем ад если они не сохраняют стабильный API.

Header libraries. Только рассортировать структурировано.

Создавать крошечные библиотеки на каждый чих

Это головная боль для сопровождения (т.е. для тебя в первую очередь). А если там еще зависимости между сниппетами, то вообще жопа. Разве что хочешь прокачать ЧСВ, заведя 100500 проектов на гитхабе. Делай одну либу и не парься. В конце концов, stdlib это тоже набор разношерстной фигни.

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

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

Следует понижать Bus Factor проекта.

То же самое другими словами: не следует ставить проект в зависимость от своей персоны: Make yourself redundant

git submodule

/thread

Это верно, но я не понимаю, причём тут маленькие библиотеки и что в них плохого.

Давай порассуждаем: у нас есть пару проектов и часть кода, который можно вынести в отдельную библиотеку.

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

Да, я могу потом далее модифицировать или забросить эти библиотеки после увольнения, или тот же Bus Factor, но (внимание!) - корпорации достаточно просто взять конкретные уже проверенные версии библиотек с исходниками и держать у себя в бэкапах вместе с основным проектом, и если им не нравится мэйнстрим - пожалуйста, у них есть код, форкайте и развивайте сами. Более того, им бы пришлось развивать код самим, если бы он был интегрирован прямо в проект.