~~NOAPPROVE~~ Когда вы основываете свой проект на основе каких-либо библиотек или фреймворков, там все просто: вы берете последнюю стабильную версию и фиксируетесь на ней навсегда (либо до момента, когда не решите обновить зависимость в будущем). Этим вы повышаете стабильность вашего проекта, отделив схему разработки вашего проекта от его зависимостей, другими словами, вы не хотите в master-версии вашего продукта ловить баги свежей master-версии вашей библиотеки. Даже если вы проводите предварительное тестирование, вполне логично отказаться от новомодных фич и возможных багфиксов в пользу того, что у вас может всплыть внезапный баг, который не относится к вашим последним изменениям.
Все становится немного сложнее, когда зависимость вашего проекта - тоже ваш проект, общий для нескольких других проектов, либо проект, разрабатываемый отдельной командой. Ваша компания заинтересована, чтобы знания (фич-реквесты, багфиксы) от всех программистов стекались в этот проект о и чтобы не было локально заточенных версий этой зависимости в разных проектах.
Для примера, пусть это будет библиотека.
Все изменения для библиотеки должны проверяться мейнтейнером этой библиотеки, как в плане кода, так и идеологически. Изменения под один проект, использующий библиотеку, не должен влиять на другие проекты. При обновлении библиотеки в проекте мы должны иметь возможность ее протестировать на бета-версиях проекта.
Исходя из всего этого мы разработали следующую схему:
(Далее есть шарепроект1, проект2 и проект3. проект 2 и 3 используют в качестве зависимости шарепроект1. Не важно, шарепроект1 - это библиотека, демон, система сборки или фреймворк)
1. создается git шарепроекта1. Бранчи master, devel и integra в нем конфигурируются как protected, изменения в них может вносить только мейнтейнер(OSV: либо workflow аля github или аля kernel.git).
2. для шарепроекта1 разворачивается система сборки, которая синхронизирует master→devel→integra автоматически, позволяет «выпускать» новые версии, выполняя восходящий merge + выпуск ChangeLog (при необходимости), запускает тесты(OSV: посути просто разворачивается свой workflow).
3. все изменения создаются в бранчах разработчиков, далее оформляется merge-request в бранч integra на мейнтейнера(OSV: или на другой бранч если другой workflow).
4. проект2, когда начинает использовать шарепроекта1, создает себе potected-бранчи master_проект2, devel_проект2 и integra_проект2, основываясь на master-бранче. Изменения в эти бранчи может вносить только мейтейнер проекта2(OSV: если это сторонний проект можно создать свой gitlab и свои original).
5. если разработчик проекта2 хочет внести изменения в шарепроекта1 ОН ДОЛЖЕН(OSV: ЭТО САМОЕ ВАЖНОЕ) оформить это в виде merge-request в бранч integra(osv: или другой мейнстрим) на мейнтейнера шарепроекта1. После приема изменений разработчик может получить изменения, подпулив в бранчи своего проекта бранч integra, либо дождаться пока они попадут в master, либо сделав cherry-pick.
6. у шарепроекта1 в бранчах *_проект2 ЗАПРЕЩЕНЫ коммиты, которых нет в основных бранчах! Это необходимо для того, чтобы использование шарепроекта1 было идеологически-верным, все изменения проходили через его мейнтейнера и чтобы максимизировать выгоду от разработчика, чтобы разработчик проекта2 при улучшении шарепроекта1 в итоге помогал всем проектам, использующим шарепроекта1. Для проектов, развиваемых внутри компании это очень важно.
Основная идея в том, что все новые изменения в шарепроекте1 проходят через мейнтейнера шарепроекта1, а решение о переносе этих изменений в проект2 или проект3 (использующих шарепроекта1) принимали уже их мейнтейнеры
7. В определенный момент мейнтейнер проекта2 обновляет свой бранч шарепроекта1/integra_проект2 до бранча master. Бранч integra_проект2 используется при сборке integra его проекта, соответственно новая версия библиотеки проходит все этапы версий integra/devel/master его проекта и тестируются. И, при этом, все эти изменения не влияют на проект3.
Для удобства сборки проекта2, его мейнтейнер может создать форк шарепроекта1 и использовать его бранчи master/devel/integra для стадий его проекта. При этом добавление новых изменений делается через merge из шарепроекта1 в его форк, а все новые коммиты уходят в шарепроекта1 через pull-request/merge-request из бранча разработчика в бранч integra шарепроекта1 и уже после их приема могут попасть в форк.
Когда шарепроектом1 не занимается отдельная команда разработки, поддерживать полный цикл master-devel-integra становится избыточно. В этом случае допустимо оставить только master-бранч и принимать все merge-request'ы в него. Благодаря тому, что это не попадает автоматом в проект2 и проект3 - считаем это безопасным.
Проект2 может забирать изменения шарепроекта1 разными способами: