Проблема вашей проблемы в том, что ваша библиотека не является библиотекой, по крайней мере, не в строгом смысле этого выражения.
Вашу «библиотеку» лучше описать как проект, которым совместно пользуются группы, работающие над различными приложениями, основанными на этом ядре.
В этом контексте самой большой проблемой является не техника подрывной деятельности, которую вы можете выбрать, а то, как вы организуете свою команду для достижения полезного сотрудничества над этим основным компонентом.
И таких проблем может быть как минимум две. Во-первых, поскольку разные приложения могут нуждаться в поведении, отличном от вашего ядра, если они плохо координируются, совершенно корректный коммит от одной команды нарушит другие (непрерывная интеграция должна помочь здесь).
Но вторую проблему труднее решить даже при хорошем межгрупповом общении, и она связана с управлением выпусками.
Если приложения, зависящие от этого ядра, выпускаются в разные моменты времени, вам будет трудно получить стабильное ядро, которое будет достаточно для выпуска одного приложения, но не остановит разработку остальных.
Мое предложение, попросите кого-нибудь посвятить себя основной библиотеке. Используйте его ветвь в каждом проекте и дайте возможность разработчикам приложений зафиксировать их, гарантируя, что они обсудят изменения со всеми, особенно с руководителем библиотеки.
И, наконец, поручите этому руководителю библиотеки координировать объединение изменений, внесенных различными командами, в ствол библиотеки, создавая таким образом стабильные, проверенные выпуски, которые будут использоваться стабильными выпусками ваших приложений. И после каждого выпуска ядра создайте ветки следующего поколения в остальных проектах.
Звучит как большая работа по сравнению с определением внешнего и позволить каждому совершать там свои действия. Но на самом деле нет смысла скрывать тот факт, что вы должны приложить некоторые усилия для обеспечения согласованности вашей основной библиотеки. Если вы не сделаете это заранее, он будет охотиться позже.