Это хорошо известная проблема во многих абстракциях развития.В микросервисах и библиотеках среда разработки обычно всегда обеспечивает обратную совместимость в некоторой степени.Это дает время другим службам, которые зависят от него, обновлять, пока старые функциональные возможности не будут удалены.Если это не вариант, так как он имеет много недостатков и требует много планирования и культуры, чтобы сделать это правильно, я бы посоветовал никогда не ломать мастера.
Поэтому мой ответ будет 3 - ветви функцийЭто хороший вариант в этом случае, так как он подходит практически для любого рабочего процесса, и его легко заставить работать с любой командой.
Причина моего выбора:
- Предложение 1 Я бы не стал использовать в качестве мастера каноническую версию программного обеспечения, если эта версия сломана, программное обеспечение сломано.Некоторые рабочие процессы разработки даже не позволяют разработчикам фиксироваться в master, где слияние выполняется только CI после прохождения всех тестов и проверок кода.Он требует затрат на управление CI, анализ кода и требует четко определенной культуры в команде.
- Предложение 2 Я предполагаю, что это означает, что разработчик 2 находится в состоянии подготовки «готового» кода.в своем компьютере просто ждет зависимости, чтобы быть готовым.У него есть место сделать что-то не так, работая над другой задачей или испортить что-то.Я всегда стараюсь зафиксировать любой код, который будет значимым или незаконченным в конце дня, чтобы избежать потери.Обычно в тематической ветке.Это спасло меня пару раз.
- Предложение 3 Подходит для меня в этом списке.Это сохраняет 2 работы разработчика, не ломает мастера и доступно для команды.Что касается взлома сборки, есть некоторые системы CI, в которых флаг в коммите мог избежать сборки, если известно, что она порвется.
- Предложение 4 Это похоже на случай обратной совместимости, но это звучит неправильно, если предположить, что эта система не похожа на такой подход, как библиотеки, платформы или микросервисы.Я также предполагаю, что у этой функциональности нет запланированного срока действия устаревания, поскольку она выглядит просто с одним модулем, зависящим от него.
Я не уверен, применимо ли это к вашему случаю, но с использованием git submodulesможет решить эту проблему, где каждый модуль будет иметь свой собственный репозиторий.Каждая зависимость - это ссылка на репозиторий другого модуля, исправленная в определенной версии.Это позволяет избежать проблем с нарушением зависимости за счет установки и обновления версии вручную.Это может быть довольно трудоемким, так как число модулей и зависимостей растет.